See example in this thread:
Using the example 317519_Docking-DataContext-SL-2.zip (though converted to WPF), I find IsHidden does not get restored from LoadLayout. If I remove the binding it works fine. But I need the binding.
11 Answers, 1 is accepted
The Save/Load layout functionality is designed to save the Docking Pane's position/size but the value of the bindings are not saved as they should come from the ViewModel. If we think of the Docking control to be the View in the MVVM pattern it should only know information of its UI (Pane positions, sizes etc.) and the ViewModel should have information about all of the bindings values.
If the values for the IsHidden property were to be saved when the save layout feature is used, it is possible that the saved value and the value in the ViewModel could be different. When this happens and the layout is loaded the RadDocking control cannot resolve this value conflict. This is why when the IsHidden property of a Pane is bound to a property of the ViewModel that value is not saved and only the binding is saved. After that if the value in the ViewModel is correct it will be applied correctly when the layout is loaded. Hope this information is helpful.
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>
I have the same problem. I want to show/hide the pane depending on some CheckBox state.
I don't really see the reason why it is not stored if a two-way binding is used. In this case, the viewmodel gets updated with the correct value on loading the layout. My ViewModel is not saved - so I don't know how to restore the IsHidden state.
Indeed it is _wrong_ the way it is now: if I close an undocked window, the IsHidden property is set to true and the container window is closed.
When the layout is restored on the next startup of the app, the container window is closed again, but IsHidden is still false. So the viewmodel thinks that the pane is visible, while it is not!
As previously discussed if the IsHidden value of the RadPane instances are saved via the built-in SaveLayout functionality the discussed value conflict could occur which cannot be resolved on the side of the RadDocking control. For full details please refer my previous response.
We tried to reproduce the issue when a floating RadPane is close and the layout is saved/loaded but to no avail. The IsHidden property is correctly set in all cases. I recorded a short video showing how the scenario run on our side. Please let us know if we missed something.
However, I don't agree with your point of view:
The IsHidden property clearly is an information about the layout which I expect to be stored when loading/saving the layout. f the IsHidden value is bound to the ViewModel in a TwoWay mode, one can assume that the ViewModel will handle this change accordingly.
I don't see any reason why I should want to store the corresponding property of the ViewModel in a different location? Or can you tell me a single real-world use case where this may be desired?
My example would be: I have a large number of tool windows which are generated and managed by the ViewModel. However, which of the windows is visible depends on the choice of the user. If the user closes one window, the ViewModel is notified that it was closed via the TwoWay-Binding, so that the CheckBox in the "View"-Menu is unchecked. The next time the application starts, the user wants to see the same tool windows again.
We understand your remarks, but please let's look at the following scenario:
1. Let's have a binding between ViewModel.IsHidden and Pane.IsHidden and the pane is visible, so the IsHidden is set to false.
2. Close (hide the pane). The value is true.
3. Save the layout and we do save the value in xml (IsHidden = true).
4. Restart the application. Now, the ViewModel.IsHidden value doesn't know what is the Pane.IsHidden value because the layout is not loaded yet, value false is restored. In the loaded layout, the value is true. The tricky moment here is how to handle such situation in one-way binding - to discard the saved value or to break the binding? We cannot assume that IsHidden property will be used only in two-way bindings, this will be a limitation which we don't want to introduce.
As Vladi already noted, we strongly suggest to save the values in the ViewModels. I hope this information sheds some more light on the given scenario.
It is very easy to check if a two-way binding is used. In this case, the IsHidden value should be stored!
We do highly appreciate our customers' opinion and I would like to thank you for your feedback. We will consider your suggestions when improving the Save/Load Layout mechanism of the Docking control.
If you have any further questions or concerns, please do not hesitate to contact us.
I have to side with Alex here. This is rather annoying. I now have to create my own methodology of saving which panes are hidden/visible separate from the rest of the layout, simply because I am using databinding. Alternatively I would have to implement commands and/or event handlers to apply IsHidden values from my ViewModel to the View to make up for not being able to databind. The point of using binding is to make things easier and more flexible, and it is pretty fundamental in WPF. Why would you implement your controls to limit their ability to utilize databinding? Kalin, the reason you provided above just does not make sense. You seem to be attempting to make up for bad coding practices with one-way binding.
Could you please open up a support ticket with really sample project demonstrating the exact requirements and scenario? This way will be able to investigate it on our side and try to suggest better solution that achieves the desired.
I'm looking forward to hearing from you.
With the next official release (R2 2016) we will be introducing brand new options to customize the Save/Load layout functionality or RadDocking. Those new options will allow you to manually save/load any needed properties and you would be to achieve the desired scenario. The release is planned for the beginning of the next month (May 2016), so stay tuned. Once the new features are live you can test this scenario and I would like to kindly ask you to share your thoughts and feedback in this forum thread when possible.
Hope this will help you.