I'm in an interesting situation where I have geometry being painted onto a canvas. In this situation I have a PatternVisual created by DataTemplate. The PatternVisual has a DataContext of Pattern. Pattern has a property, Position. Position is of type Point2d which is an immutable struct containing two properties, X and Y.
What I'm trying to do is set the Canvas.Top and Canvas.Left attached properties on my PatternVisual specified in the DataTemplate to {Binding Position.Y} and {Binding Position.X} and have them trigger updates when Position it's self changes.
The only way I've found so far to do this is using a converter to "look up" X and Y, which seems wrong to me.
Related
I have the following hierarchy in my XAML:
Grid
Ruler
Ruler
ScrollViewer
ItemsControl
ItemsControl.ItemsPanel
ItemsPanelTemplate
DrawingCanvas
Here Ruler and DrawingCanvas are my UserControls. DrawingCanvas exposes a property named MousePosition that I want both Rulers to bind to. After reading about PropertyPath Syntax, I tried the following:
Chip="{Binding RelativeSource={RelativeSource AncestorType=Grid}, Mode=OneWay, Path=Children[2].(ScrollViewer.Content).(ItemsControl.ItemsPanel).(local:DesignerCanvas.MousePosition).X}"
but this doesn't seem to work. What am I doing wrong?
Generally in these circumstances you would simply name the element you wish to bind to. It is much less brittle than finding your way through the tree:
Chip="{Binding MousePosition.X, ElementName=myCanvas}"
However, because your canvas is part of the ItemsControl template, the ElementName will not be visible to elements outside the ItemsControl.
In order to bind the two together, you need some intermediate property that both can see. One way would be to declare a DependencyProperty in your code-behind for the view. Both your Canvas and Rulers could then bind to that property using ElementName on the view root.
Another alternative is to hijack the Tag property that every element has, so in your case you could use ItemsControl.Tag as the intermediary:
Chip="{Binding Tag.X, ElementName=myItemsControl}"
<DrawingCanvas MousePosition={Binding Tag,
ElementName=myItemsControl,
mode=OneWayToSource} />
You are selecting element 3 in the Children collection which will map to the fourth element inside of the Grid. You are looking for Children[2].
PersonsViewModel has a corresponding DataTemplate with a DataGrid bound to PersonList. DataGrid.SelectedItem has two-way databinding to SelectedPerson, so that when I select a row in the view, the corresponding item from PersonList is assigned to SelectedPerson.
It works fine except for one problem: when I switch screens, say, to PersonDetailScreen, and come back, the selection focus is lost! I mean, SelectedPerson still contains its former value, but the DataGrid comes out visually unselected.
I made a test, creating a two-way databound "SelectedIndex" in viewmodel. Then, I can see the actual selection is still present in viewmodel when it comes back, the problem seems to be:
"How to focus the SelectedIndex of an ItemsControl when ViewModel's datatemplate is loaded and some "SelectedIndex" databound property in such viewmodel already contains a value?"
If you have a TwoWay Binding then you can set the DataGrid.SelectedItem value from your view model. I'm a little bit confused as to your set up though... when you say 'when I switch screens ... and come back, the selection focus is lost', it sounds a bit like you're keeping the view model alive, but not the view? I'm more used to displaying a fresh view each time, but the fix would be the same either way.
Now if this were one of my views, I'd load the data into any collections from the constructor and (internally in a base class) set the CurrentItem property that is data bound to the ListBox.SelectedItem property to the first item in the collection. You should do the same, except that instead of setting it to the first item, you'd set it to whichever item was last selected.
So the answer is just to set the SelectedItem property each time the view is displayed. However, if you're saying that the SelectedItem property is already set to the item that should be selected, you may need to set it to any other value first and then set it back to the correct item.
What are we talking about here, item selection or item focus?
If you want a visual item to get focus when a template is rendered, your best bet is to set the focus manually in your xaml's code behind, by, say, hooking a handler to your page's 'Loaded' event and setting the focus manually to your datagrid by calling on its 'Focus()' method.
I know this breaks some MVVM rules, but focus management is highly dependent on your page's visual tree, and thus cannot be properly modeled through a viewmodel, which should be as view-independent as possible.
Thanks to Sheridan's insights, I have solved the problem easier than I imagined, and somewhat unintentionally.
I had the DataGrid defined directly in a DataTemplate. When the template loaded, I BELIEVE, although I am not sure at all, that some initialization step required to pass the "SelectedItem" or "SelectedItem" value to the View was "lost".
I planned to do this re-selection manually in code behind, so what I did was to move the datagrid to some UserControl I created from scratch. But then, the very fact that the DataTemplate now instantiates a proper View (derived from UserControl) inside itself, which in turn contains the datagrid, seems to "make more notifications work", so to say, and the View displays selected row like it always should.
So, now I have this in my DataTemplate:
<DataTemplate x:Name="PersonScreenTemplate" DataType="{x:Type vm:PersonScreenViewModel}">
<vw:PersonScreenViewView/>
</DataTemplate>
That seems to be the perfect pure-WPF design pattern for ViewModel-first: a datatemplate whose content is a single usercontrol, which in turn declares and binds and handles everything.
I am building a WPF application and I have some DependencyProperties in my window's codebehind (actually a big bunch of them). I want to bind a textbox to one of these string values. If I use {Binding ObjectName} it just doesn't work and it complains about not finding the property in the output. If I use {Binding ObjectName, ElementName=window} (where window is my Window's instance name), it works. But I have lots of bindings and I don't want to use the ElementName property each time. Is there any shortcut that will default all the element names to the window objects, as all of my bindings have the same element?
Thanks,
Can.
The default source of a binding is FrameworkElement.DataContext so you have to set the DataContext property of your window to the instance of your window e.g. DataContext = this;
Can you explain the following WPF code:
DataContext="{Binding Path=PlacementTarget,RelativeSource={x:Static RelativeSource.Self}}">
I find it extremely confusing. What is placement target and what is relative source?
This looks like a hack that is used for popup-elements such as ContextMenus and Popup-windows.
The problem with these elements is, that they are disconnected from the visual tree of your window. Therefore the DataContext is not available. The PlacementTarget is a link to an element of the visual-tree.
Mostly you will find a binding path like PlacementTarget.Tag where in the source element the Tag property has been set to the DataContext but in some situations, the element itself is also meaningful, such as in your example.
Assuming that the above code is used in a ToolTip or a ContextMenu, the DataContext will be set to the control that "owns" the element.
Look at the post from (Gishu +1) for an explanation of the mechanics.
Every FrameworkElement has a DataContext that is an arbitrary object. The default source for a data binding is that DataContext. You can use RelativeSource.Self to change the source for a binding to the FrameworkElement itself instead of its DataContext. So the RelativeSource part just moves you "up one level" from the DataContext of the FrameworkElement to the FrameworkElement itself. Once you are at the FrameworkElement you can specify a path to any of its properties. If the FrameworkElement is a Popup, it will have a PlacementTarget property that is the other FrameworkElement that the Popup is positioned relative to.
In short, if you have a Popup placed relative to a TextBox for example, that expression sets the DataContext of the Popup to the TextBox and as a result {Binding Text} somewhere in the body of the Popup would bind to the text of the TextBox.
This is binding the DataContext of a thing (UI Control? need to see more of the code snippet ) to its own PlacementTarget property value.
RelativeSource is used to indicate the source object relative to the binding target. The path property indicates the name of the property on the source object.
Suppose we have an ItemsControl, which is bounded to a source.
Is there any performance difference between
ItemsControl.DataContext = resultSet;
and
ItemsControl.ItemsSource = resultSet;
(In both cases correctly binded in XAML)
Well, a performance difference doesn't really matter since the two lines do completely different things. The DataContext is the object that local databindings of the ItemsControl are taken from:
<ItemsControl Width={Binding Length} />
Will take the Length property of the object set as the DataContext and bind it to the Width dependency property of the ItemsControl.
On the other hand the ItemSource is the IEnumerable object that should be iterated to create the child items inside the control. (Each object inside the ItemSource will become the DataContext of the child item it created)