TreeView
-
Hello, On my WPF App in the main window i have a treeview control on the left and a border control on the right, I want to display different user controls in the border according to selected item in the treeview using MVVM pattern. Didn't find any good example, can any one guide me? Thanks
-
Hello, On my WPF App in the main window i have a treeview control on the left and a border control on the right, I want to display different user controls in the border according to selected item in the treeview using MVVM pattern. Didn't find any good example, can any one guide me? Thanks
Put a content control inside of the border and bind it to a content property on your ViewModel. Use the Interactivity library to attach a command to the selected node change event or the EventToCommand helper in MVVM Light. In either case, the command handler in your ViewModel will set the content property on the VM to an instance of the user control you want to display. The binding will automatically pick it up and display it inside the content control. Your user controls can each have their own view model to handle their functionality. In this way you essentially swap encapsulated views/viewmodels in and out of a container at will.
-
Put a content control inside of the border and bind it to a content property on your ViewModel. Use the Interactivity library to attach a command to the selected node change event or the EventToCommand helper in MVVM Light. In either case, the command handler in your ViewModel will set the content property on the VM to an instance of the user control you want to display. The binding will automatically pick it up and display it inside the content control. Your user controls can each have their own view model to handle their functionality. In this way you essentially swap encapsulated views/viewmodels in and out of a container at will.
Thanks for the answer, One question though, if i will set the an instance of my control inside the VM ,that means that my VM has to know about the different controls,doesn't it against the MVVM pattern concept(the view is isolated from the model,the view have reference to VM but not the other way around)? Thanks
-
Thanks for the answer, One question though, if i will set the an instance of my control inside the VM ,that means that my VM has to know about the different controls,doesn't it against the MVVM pattern concept(the view is isolated from the model,the view have reference to VM but not the other way around)? Thanks
Not really... Let's say you have three user controls; myControlA, myControlB, and myControlC. You have a MainPage with a tree view and a content control. The selection change on the tree view is passed back to the main view model via an ICommand just the same as a button or other view event. The content control is bound to a content property on the view model which is implemented as a dependency property (required to support the bindings). When a node is clicked on the tree view, the ICommand fires a method on the ViewModel. That method, in turn, creates an instance of myControlA and assigns it to the content property:
myContentProperty = new myControlA;
Because the content control's content property is bound to your content dependency property on the VM, it detects the change and updates the content presenter area with the new instance of myControlA. In your method to determine what gets loaded, you simply decide if you are creating an instance of myControlA, myControlB, myControlC, etc. This doesn't break MVVM because we aren't creating a dependency on the user controls. You could, in fact, create a content object and assign the template xaml all in code then assign it to the content DP making it show on your form. In that case, the view doesn't even exist until runtime! If you took the view model and fired it up in a test harness, you would execute the ICommand and test to see that the content property gets set to the proper user control type. The fact you can do that demonstrates we didn't break MVVM. The separation of concerns is to enable encapsulation and testing. Your view in this case is your main page and the VM is your main VM. You can't have a reference to the main view in your view model... that is a no-no... But creating a sub-view (which is itself encapsulated) is encouraged. In fact, if you look at the way App.xaml is setup, it does the same thing. Your app is actually rooted at app.xaml and mainpage.xaml is a sub-view of app.xaml. The important thing, however, is to make sure that your sub views (the user controls) DO NOT have any bindings to the main view model. They should each bind to their own view models. While it isn't strictly against the rules to bind the sub view to the main view model, it makes it easier to keep things straight with the data contexts. HTH!
-
Not really... Let's say you have three user controls; myControlA, myControlB, and myControlC. You have a MainPage with a tree view and a content control. The selection change on the tree view is passed back to the main view model via an ICommand just the same as a button or other view event. The content control is bound to a content property on the view model which is implemented as a dependency property (required to support the bindings). When a node is clicked on the tree view, the ICommand fires a method on the ViewModel. That method, in turn, creates an instance of myControlA and assigns it to the content property:
myContentProperty = new myControlA;
Because the content control's content property is bound to your content dependency property on the VM, it detects the change and updates the content presenter area with the new instance of myControlA. In your method to determine what gets loaded, you simply decide if you are creating an instance of myControlA, myControlB, myControlC, etc. This doesn't break MVVM because we aren't creating a dependency on the user controls. You could, in fact, create a content object and assign the template xaml all in code then assign it to the content DP making it show on your form. In that case, the view doesn't even exist until runtime! If you took the view model and fired it up in a test harness, you would execute the ICommand and test to see that the content property gets set to the proper user control type. The fact you can do that demonstrates we didn't break MVVM. The separation of concerns is to enable encapsulation and testing. Your view in this case is your main page and the VM is your main VM. You can't have a reference to the main view in your view model... that is a no-no... But creating a sub-view (which is itself encapsulated) is encouraged. In fact, if you look at the way App.xaml is setup, it does the same thing. Your app is actually rooted at app.xaml and mainpage.xaml is a sub-view of app.xaml. The important thing, however, is to make sure that your sub views (the user controls) DO NOT have any bindings to the main view model. They should each bind to their own view models. While it isn't strictly against the rules to bind the sub view to the main view model, it makes it easier to keep things straight with the data contexts. HTH!
Thanks!!!