I'm moving project from Silverlight to WPF and I've come across a problem.
I have a control with an INotifyPropertyChanged property GeoRect of type GeoRect. GeoRect has a variety of public properties that are set in its constructor each of type IGeoPosition.
I am setting a binding to one of these properties like so:
<TextBlock Text="{Binding GeoRect.TopRight, ElementName=x_SomeControl}"></TextBlock>
In Silverlight the default ToString method is called on IGeoPosition instance every time the GeoRect property changes. In Wpf I don't get any text at all.
I can correct this in Wpf by adding a ValueConverter to the TextBlock which simply calls the ToString method on the object, but this appears to be unnecessary fat. Can anyone help?
I suspect that there is another problem in your binding. Also in WPF, data binding calls the ToString() method to build the text of a Text-control.
Have you checked the output window of visual studio for a binding error? Or maybe the GeoRect-class does not support INotifyPropertyChanged for the TopRight property?
I guess that ElementName=x_SomeControl and GeoRect.TopRight are causing a probable "Source and Path" comination error. Are you sure your x_SomeControl has a property called 'GeoRect'? Also is x_SomeControl.GeoRect not null? And x_SomeControl.GeoRect.TopRight has a correct value?
As HCL pointed out, this will become apparent when you view your Output window where BindingExpression error must have appeared for this binding.
Please check.
Related
For years, I have felt I don't have a good understanding of WPF because I haven't found an authoritative reference on the possibilities. For example, I just found out that a ListBox has an attached ScrollViewer property.
<ListBox ScrollViewer.HorizontalScrollBarVisibility="Auto">
Other than reading a book or article that tells that, how would I know that ScrollViewer is a valid attached property? Is there a XAML schema document or something? How does Visual Studio Designer know?
ScrollViewer isn't an attached property; it's a class.
ScrollViewer.HorizontalScrollBarVisibility is an attached property. But it's not an attached property that ListBox "has"; it's an attached property that can be attached to any DependencyObject at all, including ListBox.
Here's what you see if you right click on ScrollViewer.SetHorizontalScrollBarVisibility and ScrollViewer.GetHorizontalScrollBarVisibility. A pair of static methods like this is required for an attached property. The first parameter is the thing you're attaching the property to. It doesn't have to be DependencyObject; it could be FrameworkElement, ListBox, ItemsControl, or anything else that can support dependency properties.
// Summary:
// Sets the value of the System.Windows.Controls.ScrollViewer.HorizontalScrollBarVisibility
// dependency property to a given element.
//
// Parameters:
// element:
// The element on which to set the property value.
//
// horizontalScrollBarVisibility:
// The property value to set.
public static void SetHorizontalScrollBarVisibility(DependencyObject element, ScrollBarVisibility horizontalScrollBarVisibility);
//
// Summary:
// Gets the value of the System.Windows.Controls.ScrollViewer.HorizontalScrollBarVisibility
// dependency property from a given element.
//
// Parameters:
// element:
// The element from which the property value is read.
//
// Returns:
// The value of the System.Windows.Controls.ScrollViewer.HorizontalScrollBarVisibility
// dependency property.
public static ScrollBarVisibility GetHorizontalScrollBarVisibility(DependencyObject element);
The ListBox itself quite likely has no clue what ScrollViewer.HorizontalScrollBarVisibility means, or even that it exists. But in the ListBox's template, there's probably a ScrollViewer, which will probably have a binding a lot like this:
<ScrollViewer
HorizontalScrollBarVisibility="{TemplateBinding ScrollViewer.HorizontalScrollBarVisibility}"
Put that attached property on any control that might have a ScrollViewer in its template, and if the template was written correctly, the ScrollViewer will use that value.
This is really, really nice because ListBox doesn't have to think about its own scrolling behavior. That's all delegated. Building controls by composition is extremely powerful.
The downside is that the whole thing is just a vast box of undifferentiated barf and it's real hard to make sense out of stuff. Intellisense can't tell you much about the scrolling behavior of ListBox when nobody outside that particular ListBox's template at the moment can even guess what that scrolling behavior might be.
So, in answer to your question: Yes. Basically you just have to read a lot of stuff. And keep a "Cool XAML Tricks" text file to note down cool stuff you hear about that you don't have a use for just yet.
But that's the way this profession has always been. Even with Intellisense, you can't use a class you don't know about.
Today I learned about ColumnDefinition.SharedSizeGroup and Grid.IsSharedSizeScope, and I learned that you can derive value converters from MarkupExtension and give them strongly typed, named properties instead of having to pass some goofy string into CommandParameter.
I believe the best docs we have right now are the MSDN documentation pages for WPF controls. For example, if you look up ListBox, you can find information about the attached ScrollViewer, and also it's full default template.
https://msdn.microsoft.com/en-us/library/cc278062(v=vs.95).aspx
I'm loosing it, I thought I would 'quickly' do a UserControl, add a dependency property to it and tests something, but it turns out that 'quickly' is likely to cause me to jump out the window of my 3rd floor office. I have a break point on my binding (SL5) and the FinalSource attribute (from locals) is pointing to the destination property of my control(with TwoWay binding this can almost make sense but I'm not using TwoWay binding). To add insult to injury, if I bind my control's DataContext everything works fine, if I bind my Dependency Property it does not work... (Maybe this is happening because its my last day of work for the year...). I don't know if I want an answer, but probably should, can anyone please explain this FinalSource issue to me?
Ok, found a workaround, instead of setting the control's DataContext to an instance of my presenter class I set the control's LayoutRoot's DataContext to an instance of my presenter class then all works fine. Irritating and bizarre...
To handle the TreeView.SelectedItemChanged event, I have an attached behavior that binds to a command.
Ordinarily, the RoutedPropertyChangedEventArgs.NewValue property contains a reference to one of my view-model objects, and I can then pass this on as the argument to ICommand.CanExecute and ICommand.Execute. I'm using RelayCommand from here, but I've got a RelayCommand<T> that casts to the expected type.
However, in certain scenarios, RoutedPropertyChangedEventArgs.NewValue contains a TreeViewItem, displayed as {System.Windows.Controls.TreeViewItem Header:{DisconnectedItem} Items.Count:0} in the debugger.
This causes my RelayCommand<T> to throw an InvalidCastException.
Question: what is this mysterious TreeViewItem and where does it come from?
I'm aware that I can avoid the exception by changing RelayCommand<T>.Execute from using (T)value to using value as T, but I'd like to know what the root cause is.
A DisconnectedItem is a TreeViewItem that is no longer in your TreeView (i.e. that has been removed from the tree).
Interesting; do you do anything out of the ordinary with the treeview, as in control templating? Is it the actual built-in treeview or a class that inherits it? It could have something to do with virtualization but it definitely shouldn't happen ordinarily I think.
I've been exploring WPF and XAML for a while now, but have hit a slight stumbling block revolving around binding to a method.
My situation is:
There is a ComboBox bound to a DataTable. There is a ListBox bound to the return value of a method (GetDates) via an ObjectDataProvider. One of the input parameters of the method GetDates is an Id stored in the ComboBox/DataTable.
How can I bind a MethodParameter in the ObjectDataProvider to a particular value of the SelectedItem of a ComboBox (in this case, the SelectedItem is of type DataRowView)? Alternatively, am I missing a better way of solving this problem?
I can see ways out of it by using the code-behind, but I'd like to know if there's a more XAML-y solution. It's always useful to pick up little tips and tricks, even if it turns out not to be the best fix to this problem.
http://msdn.microsoft.com/en-us/library/system.windows.data.objectdataprovider.methodparameters.aspx
This seems to describe what I need - although it's actually trying to answer a different problem.
(Aside: Is it just me or is that example on MSDN trying to do too much all at once?)
By binding the ItemsSource of the ComboBox to a DataTable, and the SelectedItem of the ComboBox to a MethodParameter (with a converter to extract the value I need from the DataRowView), the ObjectDataProvider will have the parameter it needs.
It would probably be easier to read/follow/maintain if I just hooked into the ComboBox.SelectionChanged event.
I am deriving from combobox (WinForms) and am providing a new implementation for the Selectedvalue property.
It works fine as is, but any change to the selectedvalue property is not updating other controls bound to the same "binding context" to change their values accordingly.
I did try adding the BindableAttribute(true) to the property, but still it does nottrigger the change in value to the other linked controls.
The control's DataBindings.add(...) is all set up. And other controls are also bound to the same data filed on the same datasource.
Any ideas what i am doing wrong.
Have you called your base class' implementation of overridden methods? It's possible that failing to call the base class implementation is accidentally circumventing the code that fires various event plumbing.