Using Binding.IndexerName and Binding.ProvideValue in Xamarin Forms - c#

I am trying to implement the answer in this so question
The problem is, that in xamarin forms 2 ingredients do not exist (or I have not found them yet):
Binding.IndexerName
Binding.ProvideValue()
I do not know why they do not exist. Maybe nobody has implemented them, maybe there is a technical reason why they cannot be implemented.
Can I still get the in xamarin forms?
Maybe in another way?

First, note that this answer probably doesn't work with Xamarin.Forms, or at least not with XamlC on.
If you want to get that working, your MarkupExtensions have to implement IMarkupExtension<BindingBase> instead of IMarkupExtension.
ProvideValue() is not defined in the Binding class, but in BindingExtension, but you probably won't win anything by instantiating a BindingExtension and calling ProvideValue on it versus returning the Binding directly.
The IndexerName refers to the IndexerName attribute of the Translator class. As you're not using it, the default is "Item", and you can use that hardcoded value.

Related

Get selected items in solution with native interfaces

I am trying to get all selected items in a solution and this with native code. With native code I am referring to code which does not use the DTE.
I checked the documentation and tried to find a suitable solution, however I din't come very far. What I found was the IVsUiHierarchy which contains the ExecCommand method which contains the following.
Commands that act on a specific item within the hierarchy. (If ItemID equals VSITEMID_SELECTION, the command is applied to the selected item or items.)
So I suspect the method they are talking about, is the before mentioned ExecCommand one. For one I am not quite sure how I will get to the IVsHierarchy object from a IVsHierarchy or similar, on the other hand I am not really sure on how to use the ExecCommand method properly. Additionally I am not even quite certain, if this is even the 'right way' of approaching this.
Note: I am searching for a solution which does not contain the following code in this answer.
You can use IVsMonitorSelection.GetCurrentSelection, to identify all the selected items in the solution explorer.
The above will return you an IVsMultItemSelect interface which you can use to invoke IVsMultiItemSelect.GetSelectedItems to retrieve an array of VSITEMSELECTION values.
There are a few extensibilty samples, that utilize GetSelectedItems, you can use as a reference.
Sincerely,
Ed Dore

Is there an equivalent of DependencyObjectCollection<T> for WPF .NET4.0?

The class allows the propagations of data context from the collection to its members. But it is only for SilverLight.
More info for DepedencyObjectCollection can be found from this post.
If the equivalent doesn't exist, what's the necessary steps required to create one?
I observe the desire behavior from the RowDefinitionCollection class. But I couldn't figure out its implementation.
thanks
The short answer is NO.
But I no longer think it is the correct implementation anyway. I end up using a collection of FrameworkElement and add them into the LogicalChildren of the custom control. By doing so, DataContext are passed on to the FrameworkElement naturally and everything works as expected.
It seems that that's how RowDefinition class is implemented in .NET 4.0. However, Silverlight version of RowDefinition is derived from DependencyObject directly. The MSDN document shows Silverlight documentation by default and misdirected me to the older and incorrect approach.

Updating Code, Find All Objects Of Type

Task:
Rip through all the code in the entire solution and wrap all webservice method-calls in another ws method-call that accepts a GUID (it's a login scenario)
Background :
Hundreds of web services, add token security. As explained to me when I was assigned to the task, we do it this way because if, in the future , some changes to security etc have to be made we can just do it in the WrappermethodClass in stead of having to change hundreds of web services
Tried and failed :
Find all references : too much data , returned more than 1000 hits , most of which are useless as they're only object references.
Rename WS so all references beak, build the project I'm working on and fix as I go : works well with the services not integral to the functionality but as soon as I do it with an important one it's like I shot the Solution through the brain, everything's f****d and and VS just gives up trying.
Current Solution :Open all relevant docs, Find ,select All Open Docs, skip through.
Question : How do I do this as efficiently as possible?
Code (before) :
wsGeneric wsGen = new wsGeneric();
wsGen.DoSomething();
Code (after) :
WrapperMethodClass.DoCheck takes params of (Action, GUID),
wsGeneric wsGen = new wGeneric();
wrapperMethodClass.DoCheck((g) =>
{ wsGen.UserInfo.token = g.ToString();
wsGen.DoSomething();
},Shell.token.Value);
Don´t you have some sort of interface or class where you changed the method signature already?
If you changed your webservice and your Code still compiles i´d say you did something wrong or i don´t understand the question.
Update:
I still don´t get it.
I think you have these options:
Change the method signature (all calls should be broken now, fix all the errors vs gives you and you should be done)
Find all references (of the method, not your webservice-class) and change the calls
If above isn´t possible use "Find in Files" and search for the method-name
If all your webservices inherit from an interface or base class you can refactor this method to add a parameter, all inheriting classes will also have the parameter.
If you pass a login object to each webservice, you can add a GUID element to this object and you're done.
It would be a lot easier if you showed us some code, some function interfaces that you have to change and how.
A better solution may be to just use PostSharp to add the checks to your services. This will solve your business problem (you only need to update your aspects) and is much less error prone then your current approach since you don't have to wory about some new developer forgetting to make the call to DoCheck.
Not having to find all references is a side benefit.

UITypeEditor and readonly reference type properties in .Net, WinForms

I thought I had type editors and converters nailed until I tried to persist a Readonly Reference type property after editing it in a UITypeEditor.
In my UITypeEditor, because I'm working with a read only property, I'm careful to pass back the original value (after updating the relevant sub property).
This change is reflected immediately on the designer but will not be persisted unless I do something like resize the control that the property is attached to.
To fix this I, blindly, include a call to context.OnComponentChanged() before returning the value.
I can see why this is needed. It's a reference type, I've altered it (not replaced it), and the property grid doesn't know this. I have a couple of questions for clarification:
Do I need a call to context.OnComponentChanging as well? A simple call to OnComponentChanged works in the tests I've done so far, but I don't want biting on the arse at some point in the future.
Also, is there any danger that, with my call to OnComponentChanging, I'll be persisting other components, in DesignerTransactions, that I shouldn't be persisting?

C#: Attrbute for intellisense to show method only outside of assembly

Basically what I'm hoping for is something that would work like how the Obsolete attribute works with Intellisense and strikes the method text when typing out the name. What I'm looking for is an attribute that blocks the method from being seen with the assembly it's defined. Kind of like an reverse internal. Using 3.5 by the by.
Yeah sounds odd but if you need the reason why, here it is:
My current solution for lazy loading in entity framework involves having the generated many to one or one to one properties be internal and have a facade? property that is public and basically loads the internal property's value:
public ChatRoom ParentRoom
{
get
{
if(!ParentRoomInnerReference.IsLoaded)
{
ParentRoomInnerReference.Load();
}
return ParentRoomInner;
}
set
{
ParentRoomInner = value;
}
}
Problem with this is if someone tries to use the ParentRoom property in a query:
context.ChatItem.Where(item => item.ParentRoom.Id = someId)
This will blow up since it doesn't know what to do with the facade property when evaluating the expression. This isn't a huge problem since the ParentRoomInner property can be used and queries are only in the entity assembly. (IE no selects and such in the UI assembly) The only situation comes in the entity assembly since it can see both properties and it's possible that someone might forget and use the above query and blow up at runtime.
So it would be nice if there were an attribute or some way to stop the entity assembly from seeing (ie blocked by intellisense) the outward facing properties.
Basically inside the assembly see ParentRoomInner. Outside the assembly see ParentRoom. Going to guess this isn't possible but worth a try.
I do see that there is an attribute
for stopping methods from being
viewable
(System.ComponentModel.EditorBrowsable)
but it's choices are rather slim and
don't really help.
You can use the EditorBrowsableAttribute for this:
[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
public void MyMethod() {}
One thing to know, though: In c#, you will still get intellisense on the method if it is in the same assembly as the one you are working in. Someone referencing your assembly (or your project, for a project reference) will not see it though. You can also pass EditorBrowsableState.Advanced, and then you will only get intellisense if c# if you clear the HideAdvancedMembers option in Tools Options.
I haven't heard of a good way to do this in plain .NET. But, here are some ideas. Maybe one of them will work, or set you off in a direction that will be helpful.
Use FxCop, probably writing your own rule to make sure ParentRoom isn't called from the asslembly that defined it.
Look into the various post-processing projects for .NET (link design-by-contract).
Write some code inside your ParentRoom getter which will check the stack (using "new Stack()" or "new StackFrame(1)" to figure out whether the caller was from the same assembly. If so, either throw an exception or simply return ParentRoomInner.

Categories

Resources