I'm trying to create a binding from code in a library that targets multiple frameworks (WPF, WinRT, UWP etc), and I'm hitting a brick wall. The property I'm trying to bind to is a custom attached property. In WPF, I can pass the DependencyProperty itself as the binding path:
new PropertyPath(MyClass.MyAttachedProperty)
But in WinRT the PropertyPath class only accepts a string. I tried to pass the name of the property like this:
new PropertyPath("(MyClass.MyAttachedProperty)")
but of course it doesn't work, since my class is not in the default namespace. In XAML I could map the namespace to a prefix and use that prefix, but as far as I know it's not possible to do this from code.
Is there any way to create this binding in code?
Good question, after researching and discussing we've confirmed that in UWP, we cannot programmatically binding to custom attached property. Sadly.
You may submit a request to add this new features for development through the Windows Feedback tool.
It looks as though there may be a solution here, which involves using XamlReader.Load and a resource dictionary containing the binding, to get the loader to do the work for you.
How can I bind to a custom attached property in c# from code behind in a windows store app?
Related
I am creating a component that uses a custom renderer on each platform. Let's just call it a SpecialButton element. BindableProperty works fine for values but I also want to allow a user to invoke operations on the renderer from shared code (call methods on the renderer from the Forms control code). I was looking at DependencyService as a possible solution but I don't think that will work because it is possible for multiple buttons to appear on the same page so I need the specific renderer instance that was created and linked to my Xamarin Forms element.
So, is there an elegant way for my Xamarin Forms control element to
get access to the custom renderer that was instantiated by the Forms
framework?
I had thought about exposing a property on the control and letting the renderer set itself to the property in its constructor but this feels hacky and also exposes it to the user of the control which I don't want to do.
I think I figured out a solution. I didn't realize the MessagingCenter had a source parameter which can be used to specify the element property.
MessagingCenter.Subscribe(this, "DoOperation", myButton => DoOperation(), Element);
I'm creating my first Windows 10 Universal Windows Platform (UWP) app. I'm creating a custom templated control to use in it. I've successfully created a DependencyProperty and exposed its value through a standard .NET property. My issue is applying a CategoryAttribute and DescriptionAttribute to the property so it shows in the correct section of the property grid and with the correct description. My custom control project references UniversalWindows. Is there some other reference I need to add?
You may need to create Design-Time library to provide Design-Time metadata. The library should be a WPF C# library.
The library should reference Microsoft.Windows.Design.Extensibility.dll and Microsoft.Windows.Design.Interaction.dll. Then, in the library you should have a class that inherit from IProvideAttributeTable interface to provide metadata attributes.
This is very complex， for more detail see WPF Designer Extensibility .
I have an application which use plugins. Each plugin is developped following MVVM, so I have a View, binded to a View-Model inside. like the following picture:
In my application I have a Designer, when I add any ViewModel in my ViewModels list, its view will appear in the Designer.
My question is: How can I keep this binding when adding the viewModel of my plugin in my list ?? how to make its view appear in my designer ?
This is an interesting question... and like always there are many ways to accomplish it.
It depends what your plugins are.
If the plugin is more integrated and not so isolated. You should think about some Factory classes which are for example named like ViewResolver or ViewModelResolver. They can take parameters like the name as string, a type, a type of an interface or work by conventions.
Purpose is to find the VM for a view and vice versa as a central service. This service should also locate plugin VM or import them for example with MEF.
For more info’s google on view-first, viewmodel-first, view viewmodel marriage, etc.
Or
If your plugins are fully fleshed out components which run independently. I would suggest your host application should have in its viewmodel a list of components which are the plugins. So the Model will be a Component no matter if it contains the view and everything else because of the hosting app is to manage the components. So you would have an ObservableCollection which are bound to content control. The content control can then host the plugin as a whole.
These are two possible ways... like I mentioned above there is no "the" way in mvvm and it always depends on your use cases...
But I hope this guides you in the right direction...
HTH
Thank you for the answer #Silverfighter! it made me things more clear !
I found a very intersting article wich seems adapted to my problem
The solution is here:
http://www.alphablog.org/2012/05/07/simple-plugin-system-based-on-ninject-and-mvvm-light-2/
Hi basically I've been able to completely seperate my logic into a view model with the exception of one thing. I have a a button and two different templates that can be applied to the button. Basically when audio is playing one template is displayed and when its not the other is displayed. When I was using the code behind this was easy because I had access to the page's Resources and all I had to do was set it accordingly. Now that my code is in the VM though I'm not really sure how to change the template.
The first thought that comes to mind is to maybe send a message to the view to change it when I need to. Is this the only way? I did see that WPF had triggers which looks pretty nice because you don't have to send messages and no code is placed in the code behind. Has anyone found a work around for this?
You can probably write a ValueConverter that would look at a public bool IsPlaying property and transform it to the appropriate template. Then you can databind your Button template property to the IsPlaying property, using the converter as a translator.
I haven't tried this with templates, but I've used it to great success with Bitmap and Visibility, so I'm pretty sure it would work here as well.
Here's a good intro to ValueConverter, if you haven't used one before.
That said, messaging isn't such a horrible solution in this case. Sometimes there is code that just wants to live in the codebehind file. Animation start/stop code is another example that comes to mind.
Can IDataError info be used properly in a winforms application? In the past I was doing my binding the usual way(1) and did the validation in the OnValidating event of the particular control. I would like to move the data validation to the domain model so that I can easily swap out user interfaces and so that all of the logic is in one place.
I was looking into IDataErrorInfo but everything I find deals with WPF and the app in development is strictly a winforms app.
I also noticed that the binding that gets used in WPF is in System.Windows.Data and the binding that I've always been using is in System.Windows.Forms (which I don't appear to have when I try to add it as a resource - I'm using 3.5).Aside from the property "ValidatesOnDataErrors" is there a difference between the two?
(1) the usual way being:
myControl.DataBindings.Add(new Binding("Text", this.domainModel, "Property"));
This works with the ErrorProvider component in Windows Forms.
For a complete, but very simple and short tutorial, see this blog post.
Yes, IDataErrorInfo works in winforms. For example, DataGridView will use this automatically both per-row and per-cell. But it is implementation-specific, and isn't automatically applied to other bindings. I did once write some code to associate it to an error-provider and do the work via change events, but I don't have it to hand unfortunately. But I seem to recall it wasn't huge.