I have a WPF TabControl with two TabItems. In both tabItems I have a textbox with the Text property bound to a property in my ViewModel. The problem is that the binding in the second tab (the one "hidden" by the first tab) is not working. I have two cases:
I run the app, I run the command that would fill the text in the second tab, I select the tab: in this case the binding works: I can see the textbox filled with data. But if I run again the command the textbox does not get updated anymore. It looks like the binding works, but only once.
The second case is if I run the app, and then, before running the command, I select the second tab. In this case the binding does not work at all.
If I move the second tab to the first position, then the binding will work for this tab. (but it will stop working for the other one)
Does someone knows about a worksround for that
Your ViewModel has to implement INotifyPropertyChanged interface.
Also you have to set the UpdateSourceTrigger property of your binding to "PropertyChanged". After this changes your app should working as expected.
Related
My application has two tabs in a TabControl.
I have (model) class (implementing INotifyPropertyChanged) bound to a the controls in the first tab via DataConext. Data binding works fine. I then replace the instance assigned to the DataContext with a new instance. Then the new values are not shown. As soon as I switch to the second tab and back the values are visible. It appears as if the data binding need some kind of kick ass to start working.
How could I force the view to re-bind programmatically?
Background:
I use converters to acquire values for most of my binding statement because the bindings are so complicated that even multi-binding cannot satisfy. I have to calculate the value in the converters and return the value. Also I use OneWay or OneTime binding just to show the correct value. When user changes a value, I use Handlers to set the value. The Handlers are also complex program which cannot be simply replaced by TwoWay or OneWayToSource binding. Actually in this case the DataContext does not have any meaning. I use converters. Another reason of using converters is that all Controls are loaded dynamically using many DataTemplates and it's hard to create dynamic DataContext for each Controls in each DataTemplate.
With above background, my application works fine. I'm looking for solutions for our new problem below.
I have many group of Buttons each represent a warehouse containing different type of items.
When double-click a Button, a detail window pops up and user can modify the items. Those items can be represented by CheckBox, Combobox, TextBlocks, TextBox, etc.
For user's convenience, I duplicated some of the frequently-modified Controls from the popup window onto the Button itself (WPF allows Button to contain sub-controls), so that user can directly modify the items without double-click and popup the detail window.
Each Button could contain unknown number of sub-controls such as CheckBox, Combobox, TextBlocks, etc. Here "unknown" means that in the future developer can duplicate any controls onto the Button if the Controls for those items are deemed frequently-modified.
Everything works fine so far.
When user modifies an item in the popup window and closes the window, I used to reload the DataTemplate for the whole window so that everything is refreshed and the controls duplicated onto the Button can synch up with the value modified from inside the popup window.
Everything still works fine so far.
The problem happens when the application runs on machine with slow hardware, where performance is an issue. On a much slower machine, reloading the whole DataTemplate for the whole application that contains many Buttons is quite slow.
So I'm looking for ways to just refresh the Button that is double-clicked, not all Buttons. However, I searched a couple of days and could not find ideal solution of refreshing a WPF sub-tree.
I tried to travel the sub-tree of the Button to assign null to the DataContext property and then assign back the old DataContext, but the binding seems not triggered and the converters were not called.
I saw someone suggested to use something like below:
((ComboBox)sender).GetBindingExpression(ComboBox.ItemsSourceProperty)
.UpdateTarget();
That demands that I know the Control and its property that has bindings. I think I can do the same for all possible Controls and properties but it does not seem a future-proof solution.
Anybody knows an effective way of refreshing a WPF sub-tree without knowing what is in the sub-tree?
I need to set focus to UserControl itself, not its child.
Otherwise I cannot implement insertion from the buffer. :(
Setting Focusable=True doesn't help.
Google and SO tells only how to set focus to UserControl child.
My control contains:
- Toolbar with several buttons bound to commands of the corresponding
VM
- TextBox which is the input for the filter
- DataGrid - list of items.
I need to bind Ctrl+V command to VM. But to handle this gesture UserControl must have focus within. When there are no items in the grid (VM's collection is empty) buttons are disabled and the only element which can get focus is TextBox. But it handles Ctrl+V in its own way and I don't want to change this behavior.
Thus, I need something to set focus to when I click the area of UserControl.
I believe UserControl is the best candidate for it.
But I don't know how to make it selectable.
The whole problem was in my misunderstanding of controls' behavior.
This SO question clearly shows it I believe.
Thus, setting UserControl.Focusable = true is not sufficient. To make it navigatable via keyboard IsTabStop must be true also. And to make UC selectable by mouse click we should call Focus() in mouse eventhandler. That's it.
I have buttons on my Silverlight page where the opacity is bound to one of two properties on my ViewModel. I'm using the button command that changes the properties, in theory to affect all buttons bound to that property, but the only control that gets affected is the button that initiates the command (any one of them).
Any ideas on why the additional bindings don't work?
The whole thing is actually a little more complex where the buttons are on a Control with the bindings as DependencyProperties mapping back to the VM, and the bound properties are going through a ValueConverter.
It sounds like you need to raise the INotifyPropertyChanged.PropertyChanged event for the properties that are changing. This will let the controls that are bound to them know that there is a change and that they need to come back and get the latest value.
I found the problem. The opacity binding wasn't working, but what was happening was the button was disabling itself based on the predicate I had set in the RelayCommand. It looked like the effect I wanted, but only affected the button being pressed because each button was bound to a seperate ICommand.
I changed it to remove change the binding from the OpacityProperty to the IsEnabledProperty, and removed the predicate from the RelayCommand declaration. It all works now as intended.
I don't know why the button would change to a disabled view when it checks the predicate (and finds it false), but never change back if the condition changes. Odd.
I have a WPF ListView that is bound to a BindingList<T>. The binding works like a charm, but I have to tab out of the cell to get the bound property to update....this is an issue because most users don't tab out of the last column before clicking the save button.
How do I force the list view to "persist" the changes to the bound DataContext without doing something hackish.
Bindings in WPF have a property called "UpdateSourceTrigger" which tells the Binding when to update the thing the UI is bound to. By default, it's set to "LostFocus" for the Text property which is what you're most likely using.
Change the trigger to "PropertyChanged" in your binding like this:
Text="{Binding Foo,UpdateSourceTrigger=PropertyChanged}"
... and now the source "Foo" property will be updated as the Text changes in the UI.
There's also an "Explicit" setting for UpdateSourceTrigger which is handy if you need to hold off writing any changes to the source until, say, the user clicks the OK button.