Is it possible to dynamically get the binding properties for a view into a class and manipulate it in run time.
for example, if the DataContext is of type User that has 10 properties, but the bound properties are only 4, can I make a class that has these 4 properties only?
Doable, but difficult.
You must parse the visual tree, and visit every control using VisualTreeHelper (see: https://stackoverflow.com/a/874426/275330).
For every control you can get a list of its dependency properties (see https://stackoverflow.com/a/26367132/275330)
Then for each separate dependency property you can check if its value is set locally (see: Knowing if a DependencyProperty has not been set in XAML). If so - you have the value you need.
I've never used 1+2+3 together, so I don't know what additional difficulties you may have.
Related
I created a user control that have multiple dependency properties that work correctly. My problem is that when I create multiple user control instances and bind the same DP on the same external property and I modify the second instance of the User Control the input for the first instance will be also modified and I don't want that. Is there something like a x:Shared property for DP's that will keep each DP with his instance?
I don't think this question needs code attached because is somehow a general question.
Regards
Looking for a way to automatically verify, using unit-tests for example, that all controls in my WPF application are set to Binding.
I'm using data-binding to enable localization in the application.
For example, a TextBlock control in a view will have it's Text property binding to 'SomeLocalizedLabel' property in the view model.
I need to make sure that I won't miss any control, and all my 'TextBlock' controls have their 'Text' property bound to something.
I can check the correctness of the localization itself in the ViewModel level.
I can check that all public ViewModel properties are bound to something in the view using the Caliburn.Testability assembly or some other method.
The thing that missing here is to test the View level.
UI testing framework is not the solution I'm looking for, because I wish for something that can be written and executed fast.
See my post here:
How to check if a XAML element supports AutomationId attribute
You could use the mechanisms mentioned to go through all your XAML and look at the Text properties of elements, and decide if they have missed a Binding.
LocBaml is a tool that goes through the XAML to extract localizable properties....your rolling your own localization technique...but I'm sure you can adapt that to extract check "Text" properties and see if they have a binding, then produce a report where they are not.
How can I find and access to Elements which are bind to an object in XAML ?
Edit : Let's say I have a EmployeeViewModel which is assigned to EmployeeView's DataContext and a EmployeeModel inside my EmployeeViewModel, I want to know which properties of my model bounded to View's Framework Elements (Controls) also I want to have an access to each control bounded to my model properties.
UPDATE: In light of the question being clarified by SaberAmani in that he is trying to add validation to his models and show a validation summary..see the links below.
http://msdn.microsoft.com/en-us/magazine/ff714593.aspx
http://codeblitz.wordpress.com/2009/05/12/wpf-validation-summary-control/
http://wpfvalidation.codeplex.com/
http://f10andf11.blogspot.co.uk/2012/02/wpf-validation-summary-control.html
For reference for people that want to discover Bindings:
You don't mention if your XAML is in WPF, Silverlight, Metro or Phone7 (thus you may be more restricted in what you can do).
There seem to be a few possible ways to do what you want:
Reflection
MarkupObject / MarkupWriter
TypeDescriptor+DependencyPropertyDescriptor
Custom Binding Markup Extension
Take a look at this link.
http://blog.spencen.com/2008/05/02/how-to-get-a-list-of-bindings-in-wpf.aspx
He uses reflection and suggests this is the classical way to do it...but also mentions MarkupWriter as another possibility. NOTE: the reflection method doesn't discover Attached Properties which may have bindings.
Here are some links that use MarkupWriter...this would allow you to discover the attached properties.
http://www.codeproject.com/Articles/21139/An-XAML-Serializer-Preserving-Bindings
http://blogs.msdn.com/b/marlat/archive/2009/05/24/getbindingexpression-a-good-way-to-iterate-over-all-dependency-properties-in-visual-tree-in-silverlight-3.aspx
Related links:
Retrieve all Data Bindings from WPF Window
Getting list of all dependency/attached properties of an Object
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/580234cb-e870-4af1-9a91-3e3ba118c89c
you could use reflection to loop through properties and use FrameworkElement.GetBindingExpression on each property to build, for a given Framework element, all its bindings.
http://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.getbindingexpression
I'm looking for a data-driven WPF property grid/editor.
Most property grids appear to work using reflection to figure out the CLR properties on your class. Those properties are then displayed in the grid with editors that are specific for the type of the property.
However I don't have a specific class that I want to plug into the property grid. All I have is data, specifically a collection of name/value pairs. I want to put this collection into the grid and have a editor that is specific for the value type of each pair.
Does anyone know of an existing property grid/editor control that supports data-driven properties?
Also if it looks like the property grid/editor in Blend I won't complain ;)
I've never used it, but from what I've read about the PropertyTools for WPF on codeplex.com supports dynamically editting the current selected object.
http://propertytools.codeplex.com/
I have a DataTemplate consisting of a media element control that is derived from MediaElementBase from the WPF Media Kit library. The MediaElementBase class provides the two properties, LoadedBehavior and UnloadedBehavior that allow the user to specify what happens when the element is loaded/unloaded.
I am finding that when using this in a DataTemplate (as follows), these properties get reset to their default value when the template is unloaded, but before the Unloaded event is called, meaning only the default UnloadedBehavior will ever execute:
<DataTemplate DataType="{x:Type Channels:AnalogChannel}">
<Controls:AnalogTvGraphFileElement
LoadedBehavior="Play"
UnloadedBehavior="Stop"
Channel="{Binding}" />
</DataTemplate>
This doesn't occur when the control is simply an element on a page and Unloaded occurs through a normal navigate-away event.
Debugging the DependencyPropertyChanged EventHandler reveals that an internal method System.Windows.StyleHelper.InvalidatePropertiesOnTemplateNode (in PresentationFramework.dll) checks if a DependencyProperty is potentially inherited, and if it isn't, invalidates it. Sure enough, changing the property metadata for the LoadedBehavior / UnloadedBehavior to add FrameworkPropertyMetadataOptions.Inherits stops this property from being reset when the template changes.
Does anyone know why this occurs? I can add the Inherits flag as a workaround, as this element has no child elements that would be affected by this, but I'd like to know why / whether it is the right thing to do.
If you're after more information about what I'm doing and why I'm changing DataTemplates you can view this question for a description.
Rather than putting this element directly into the template, have you tried creating a user control that contains your AnalogTvGraphFileElement element, and then using that user control in your template?
If the problem here is being caused by the template systems going and unsetting properties that it set in the first place, moving your element into a user control should help, because the properties would no longer be being set from the template.
As for why you're seeing the behaviour in the first place, as far as I can tell the relative ordering of the Unloaded event and the loss of properties set via the template is not documented, so you shouldn't depend on any particular ordering. The fact that you will lose the property values is documented. (Or at least, it's implicit from the docs.) The WPF property system treats local values in a template as being a different sort of thing than normal local values outside of a template. See this MSDN page on dependency property precedence - 4b indicates that local property sets in the template are not the same thing as local properties. (It seems odd to make a distinction, but it should be possible to set property values from both sources by setting them in the template - type 4b - and then at runtime, going and finding the element in a particular instance of the template and setting its local value from code - type 3. And for that scenario you really would want type 3 local values to have higher precedence than type 4b local values.)
Weird as that seems, it might make more sense when you consider that a single template may be providing values for multiple instances. You've got just one local property setter that could affect any number of elements. (This means that a simple mental model of a template as being a factory that builds a visual tree and sets properties on that tree would be wrong. It's a factory that builds a visual tree, but it doesn't set properties. The property system simply ensures that in the absence of any higher-precedence property value sources, the elements in a visual tree that's the template for something will pick up values from setters in the template.)
That page does just about tell you that type 4b properties will disappear once the template ceases to be active - the template is no longer the template for the templated parent, and so any local values provided by that template no longer qualify as candidate values of type 4b (or any other type for that matter) for the property. In short, once the template ceases to be the template for something, it ceases to have any business providing values for that thing or anything in it. This implies that the visual tree for an instance of a template enters a weird limbo state in which it is no longer the template for anything but hasn't yet unloaded.
Of course, it doesn't seem useful for the template to stop providing values before the relevant visual tree has finished unloading, but perhaps properties whose value is only significant when an element unloads are a bit of a weird case, and not one that was specifically designed for. Thinking about it, they probably shouldn't ever be dependency properties - almost all the features that make DPs useful don't really mean much once you're unloaded from the visual tree. So arguably, it's a bug in the Media Kit that UnloadedBehaviour is a DP in the first place.
It's inconsistent that inherited properties (type 10) shut down later than local template property sets (type 4b), but then I'm not sure it's reasonable to expect any particular order here. It's not obvious that the documentation implies one order or the other, so either order is correct...and WPF appears to make use of that by picking one order in one scenario and the other in another scenario.