i just curious why when i access most controls via x:Name, for resources i do so using x:Key + i cannot access it from code (could using this.Resources["keyName"])
•x:Key: Sets a unique key for each resource in a ResourceDictionary (or similar dictionary concepts in other frameworks). x:Key will probably account for 90% of the x: usages you will see in a typical WPF application's markup.
•x:Name: Specifies a run-time object name for the instance that exists in run-time code after an object element is processed. In general, you will frequently use a WPF-defined equivalent property for x:Name. Such properties map specifically to a CLR backing property and are thus more convenient for application programming, where you frequently use run time code to find the named elements from initialized XAML. The most common such property is FrameworkElement.Name. You might still use x:Name when the equivalent WPF framework-level Name property is not supported in a particular type. This occurs in certain animation scenarios.
for that reason you have to use Key for the Resources
mor on http://msdn.microsoft.com/en-us/library/ms752059.aspx
You can access resources on any FrameworkElement as long as the element contains any resources. If defined in your markup, it must have a x:Key and cannot have a x:Name.
If a Button contains the resource for example, you must access it from its Resources collection.
var resource = button.Resources["myKey"];
If you want to find a resource from an object, its parents or the application, use FindResource() instead.
var resource = this.FindResource("myKey");
I don't understand your confusion.
Related
I'm wondering what element can be used, when the only thing you want to change is the DataContext.
I'm aware that I could wrap it in a grid or something, but all of those are rather heavy weight when I just need to change the data context for a single element, so that I can more easily bind to attributes without them getting too long.
The concept of the WPF class hierarchy is described at Microsoft: WPF Architecture. There you can find the System.Windows.FrameworkElement:
The two most critical things that FrameworkElement introduces are data binding and styles.
Checking the properties of FrameworkElement, there the DataContext property is defined. This means the following capability is available:
Support for data binding and dynamic resource references: The property-level support for data binding and resources is implemented by the DependencyProperty class and embodied in the property system, but the ability to resolve a member value that is stored as an Expression (the programming construct that underlies both data binding and dynamic resources) is implemented by FrameworkElement. For more information, see Data Binding Overview and XAML Resources.
The DataContext property is now available and used at all inherited controls, which you can see at the following class hierarchy:
I have this problem with my listview itemsource, you see I'm working in WPF, and the problem comes (I think) in VB, its like blocked, this new columns I added I cannot see in xaml, the columns are there but no info, and I can see the values if I put some breakpoints in the part I specify the itemsource list, and when I do this shows up:
That lock there most be the cause of my problem, but I do not know how to take it off my collection list. HELP PLEASE.
By the way I'm using properties to create a row and later bind that to xaml
You can't see that property in the list view because it is marked as Private. According to the documentation all binding source properties must be marked as Public.
Binding Sources Overview | Microsoft Docs:
Implementing a Class for the Binding Source
(...)
Other Characteristics
The properties you use as binding source properties for a binding must be public properties of your class. Explicitly defined interface properties cannot be accessed for binding purposes, nor can protected, private, internal, or virtual properties that have no base implementation.
The little padlock that you see on the icon doesn't mean that it's locked, it's just an indication that the property is marked as Private.
If Resources dictionary is not observable, how does DynamicResource reference work?
Do the Add / Remove methods of the resource dictionary have internal code that kind of "polls" all DynamicResource references and refreshes them when they are removed or added?
Each ResourceDictionary contains three list of owners. One for FrameworkElement, one for Application and another one for FrameworkContentElement. When you access the Resources property the owner is being set. Also each ResourceDictionary propagates its owner to merged dictionaries. When dictionary is changing, it notifies owners about it. This notification actually searches dependency properties with local values containing resource expression. Then each expression is forced to reevaluate.
All of this code is internal.
e.g.
TextBox has a Text property, but I cannot bind to it, if I am going to bind, I have to bind to the TextProperty dependency property.
e.g.
textbox.Text = new Binding("mypath"); does not work
and I need
textbox.SetBinding(TextBoxBase.TextProperty, "mypath")
BUT, and this is a huge but, I don't know that it is property "textbox.Text" until runtime. I'm trying to set the binding via relection information, so I know I have a framework element, and I know i have some property. it might be text, it might be itemssource, or something else.
so given an arbitrary property that is backed by a dependency property identifier, how can i find the dependency property identifier for that property?
While not required, the strongly encouraged convention is to append the word Property to the CLR property when naming the DependencyProperty field. I would start by looking for that.
The System.ComponentModel.DependencyPropertyDescriptor class may help you out here.
However, my recommendation would be to ask, from a larger perspective, why do you believe you need to choose that binding at runtime? I suspect there's probably a better way.
A little background: I am loading a WPF UI from a database which is stored in a table of properties (Control type, label, margin, etc.) which I load into a class I call ControlPresenter. Basically I set ControlPresenter as the DataContext of a ContentPresenter and use a TemplateSelector to choose which type of control to load. The DataTemplate(s) load their properties off the DependencyProperties exposed by the ControlPresenter.
This all works extremely well. The problem I'm running into comes when I try to bind data (e.g. TextBox's Text property to a presenter's Name property) in other presenters (which have normal properties that implement INotifyPropertyChanged) to these controls. The control's DataContext is the associated ControlPresenter so I can't bind directly to the other presenters and I can't set up two bindings on the same dependency property (I can't bind the control and the desired presenter property to the same DP).
Possible solutions:
I could convert all of the other presenters to use DPs (extremely time consuming and prone to cause problems with inheritance)
I could use two DPs for each property I want to pass through and try to tie them together through changed notifications
Both of these seem problematic and prone to breaking so I'm hoping someone else has come up with a better solution.
Edit: I came up with a solution that works fairly well (see below). Thanks to everyone that looked at this and if you come up with a better method than I did please let me know.
There are several ways of accessing out of scope DataContexts.
1) ElementName Binding
This is probably the least useful as, in most real world scenarios, what you are trying to bind to is out of namescope anyway. But it is a way to access a parallel or parent Data Context as long as the Framework Element is within namescope.
<TextBox Text="{Binding ElementName=ControlSomewhereElseBoundToSomeOtherControlPresenter, Path=DataContext.SomeTextPropertyOnTheControlPresenter}" />
2) RelativeSource Binding
This is similar to #1 but using RelativeSource to navigate to the appropriate visual element and grab the DataContext. Of course, this assumes that the DataContext you are trying to get at is ABOVE where you currently are in the Visual Tree.
3) Use a Static Relay
You could expose your alternative ControlPresenters within a static class that acts as a facade to your ViewModel. Then, within each ViewModel construct instance properties that pass through to the static methods / properties. This is a common way for achieving shared storage across multiple View Models. I realize this technique would require you to alter your pattern a bit, but adding a simple ViewModel wrapper around these "ControlPresenter" classes seems a lot more simple than the options you described.
I ended up setting the bindings in code by setting Binding.Source to the desired ViewModel and then using the path in the database for Binding.Path. I store the bindings in a Dictionary(Of DependencyProperty, BindingBase) and when the Control loads I use BindingOperations.SetBinding to set the bindings on the control. This seems to work pretty well except for occasional order of operations issues (e.g. If you set SelectedItem/SelectedValue prior to the ItemsSource it will be set but won't display in a ComboBox).