Click here to Skip to main content
15,867,453 members
Home / Discussions / WPF
   

WPF

 
AnswerRe: Another DependencyProperty Question Pin
Pete O'Hanlon5-Sep-13 20:24
subeditorPete O'Hanlon5-Sep-13 20:24 
GeneralRe: Another DependencyProperty Question Pin
Kevin Marois6-Sep-13 3:50
professionalKevin Marois6-Sep-13 3:50 
GeneralRe: Another DependencyProperty Question Pin
SledgeHammer016-Sep-13 5:07
SledgeHammer016-Sep-13 5:07 
GeneralRe: Another DependencyProperty Question Pin
Jason Gleim6-Sep-13 5:23
professionalJason Gleim6-Sep-13 5:23 
GeneralRe: Another DependencyProperty Question Pin
Kevin Marois6-Sep-13 6:59
professionalKevin Marois6-Sep-13 6:59 
GeneralRe: Another DependencyProperty Question Pin
Jason Gleim6-Sep-13 7:28
professionalJason Gleim6-Sep-13 7:28 
GeneralRe: Another DependencyProperty Question Pin
Kevin Marois6-Sep-13 7:54
professionalKevin Marois6-Sep-13 7:54 
GeneralRe: Another DependencyProperty Question Pin
Jason Gleim6-Sep-13 9:03
professionalJason Gleim6-Sep-13 9:03 
I see I was getting a bit snarky in the previous reply. Sorry about that... I shouldn't do that. Please accept my apologizes.

Now, onto your questions...

MVVM is about separation of concerns but it is the WHY that really drives the structure. The idea is that if you remove "backward" dependencies, then you can swap layers in and out or reuse them. So the view depends on the view model but you can't have anything in the view model depend on the view. Similarly, the view model depends on the model (if implemented) but the model can't depend on the view model at all. If implemented this way, you can reuse the code at the VM and M levels. A single model could support multiple VM's. A single VM could support multiple views. Imagine, for a second, that you had an app that the main view displayed a list of customers. Supposed that your default view was a grid listing of those customers. What if you wanted to show them as tiles that could be rearranged? That would probably be best done in a different view. While you would only have one active view at any time, both views would bind to the same view model where you would maintain the data and the state. For example the "selected" customer shouldn't change if the user simply changes views. If you put anything that is outside of the scope of a single view in the code behind, then you have issues of scope and possible coupling between your view(s) and your view model(s). That is the reason to avoid putting code in the code behind. It is easy to say that it is no big deal when you have a 1 to 1 to 1 mapping. But it becomes a big deal when that changes. So the best practice is to avoid it so you don't have to go back and refactor if something changes.

And... that really answers the questions about dependency properties. DP's are used by the binding system to hook-up properties between two classes for automatic synchronization. If you are going to bind two properties (which is what you are doing with the selected row on the treeview and the corresponding property on the view model) then ONE of them has to be a dependency property. So a DP hooked to a DP will work. A DP hooked to a regular property will work. But a regular property hooked to a regular property will not work. The binding framework in this case, can't resolve the property name raised in the propertychanged event because the framework uses the dependency property system to resolve the property names and update the values.

The DP system is a static class so there is one instance of it for your application and it is automatically created the first time it gets called. Think of it as an impartial 3rd-party. If you look in the sample code provided in one of the other answers you will see where the public SelectedJob property gets registered (via the Register method of the DependencyProperty static class) with the DP system. The DP system now knows about the SelectedJob property on your view model. We usually pair the DP registration code up with the property code in the view model because the getter and the setter for the property must now GetValue and SetValue the backing dependency property. Once registered as a DP, the regular public property uses the DP system as the backing store so it is really just a proxy to make it easier to code against. The presence of the public property lets you write:

SelectedJob = new myJobClass;

rather than:

SetValue(SelectedJobProperty,value);

More importantly, the public property allows you to set the binding in xaml in a format that makes sense. So your SelectedJobs dependency property can be bound with:

XML
<treeview SelectedItemEx = {Binding SelectedJob, mode = TwoWay} />


The binding system looks in the Dependency system to find SelectedJobProperty (the DP object for the SelectedJob property) at runtime to handle property updates.

The upshot of all of this is that the dependency system matches up the properties at runtime providing a level of indirection between the VM and the view. Because the VM depends on the DP system and the view depends on the DP system, they don't depend on each other and you achieve the separation we are after. The same sort of system is used for commands to go the other way (from the view to the viewmodel).

Since the base property we want to link up is exposed on the view model, we typically pair the DP code up with the property in the view model code. Since the VM only gets instantiated once, we can be sure that the DP only gets registered once. If we put the DP code in the code behind, we couldn't use the DP until the view was instantiated. Back to our example of where we have two views and one view model... now it suddenly doesn't work to put the DP code in the code behind. Do we put it in the first view or the second? Do we put it in both? What happens if we do that? How do we keep from getting an exception thrown because the property is already registered with the DP system? We avoid all of those questions by putting the DP code with the property we are registering in the view model.

Since the DP system is a static third-party and the binding system already knows how to locate it and use it, there is no concept of scope to worry about. Even though we put the code for the DP in the view model, all we are doing is calling the register function and passing in the property information. Technically we could put that anywhere and as long as the VM was instantiated before the call to register, it would work. Mull on that for a moment... you could technically create an instance of your VM in the app.xaml.cs code behind and put the call to register the property with the DP system right after it and it would still work. That goes against convention and it would make it tougher to maintain the code, but it would work.

So my initial statement that the DP code should be in the view model is a best practice and not a rule that is caused by some limitation in the framework. And you most certainly can put it in the code behind. But I hope you can see there are good reasons to pair it with the property on the view model.

Now, with all of that said, I'll probably ruin your day. Remember when I said that ONE property in the equation had to be a DP for the binding to work? The SelectedItemEx on the TreeView is probably already a DP based on the fact that the property on your view is being set when you click on a job. You can bind a property on ANY OTHER CONTROL to that same property on the view model provided the control's property you are hooking up is a DP (and most all of them are). Making the property on your VM a DP will not solve your scope problem and somehow make it available everywhere else. The binding system will ONLY look for properties scoped to the current data context. You need to manage the data context of the host and the wizard to get to the selectedjobs property.

Assuming you have a separate view model for the host and one for the wizard, they need references to the view model that contains the selectedjob. If you are using the MVVM light framework, you can use the Locator class to get the instance of the job view model in the other two view models. Otherwise, you need to create a public static instance of that VM in the app code behind or the main view (host?) code behind and pass it to the constructor of the host VM and/or the wizard VM exposing it as a property on those two view models. Then the selected job (to the host) becomes

hostViewModel.jobViewModel.SelectedJob

The binding would then be:

hostControlProperty = {Binding Path=jobViewModel.SelectedJob}

Assuming hostControlProperty is a DP, there is no need to make SelectedJob on the view model a DP. Indeed, if this is your structure, you MUST have a reference in the host to the VM containing the property regardless of whether it is a DP or not.

The same would be for the wizard. You would need a reference to the job view model in the wizard view model to get access to the property.

Finally, if you don't want to do that... maybe the selected job is the only thing you need... I suggest creating a static class or one using the singleton pattern that exposes a SelectedJob property and implements INotifyPropertyChanged. Use it as the backing store in your view models. Then you have one, global instance of the SelectedJob and you can expose it as a property on any view model you want.

HTH,
Jason
GeneralRe: Another DependencyProperty Question Pin
Kevin Marois6-Sep-13 9:40
professionalKevin Marois6-Sep-13 9:40 
GeneralRe: Another DependencyProperty Question Pin
Jason Gleim6-Sep-13 10:39
professionalJason Gleim6-Sep-13 10:39 
GeneralRe: Another DependencyProperty Question Pin
Jason Gleim6-Sep-13 10:53
professionalJason Gleim6-Sep-13 10:53 
GeneralRe: Another DependencyProperty Question Pin
Kevin Marois6-Sep-13 13:01
professionalKevin Marois6-Sep-13 13:01 
GeneralRe: Another DependencyProperty Question Pin
Kevin Marois9-Sep-13 7:12
professionalKevin Marois9-Sep-13 7:12 
GeneralRe: Another DependencyProperty Question Pin
Jason Gleim9-Sep-13 7:55
professionalJason Gleim9-Sep-13 7:55 
GeneralRe: Another DependencyProperty Question Pin
Kevin Marois9-Sep-13 8:01
professionalKevin Marois9-Sep-13 8:01 
GeneralRe: Another DependencyProperty Question Pin
Kevin Marois6-Sep-13 8:22
professionalKevin Marois6-Sep-13 8:22 
GeneralRe: Another DependencyProperty Question Pin
Pete O'Hanlon6-Sep-13 6:06
subeditorPete O'Hanlon6-Sep-13 6:06 
AnswerRe: Another DependencyProperty Question Pin
Richard Deeming6-Sep-13 4:22
mveRichard Deeming6-Sep-13 4:22 
GeneralRe: Another DependencyProperty Question Pin
SledgeHammer016-Sep-13 5:08
SledgeHammer016-Sep-13 5:08 
Questionneed a coah for a WPF projet Pin
vanjier4-Sep-13 6:17
vanjier4-Sep-13 6:17 
AnswerRe: need a coah for a WPF projet Pin
Pete O'Hanlon4-Sep-13 6:31
subeditorPete O'Hanlon4-Sep-13 6:31 
GeneralRe: need a coah for a WPF projet Pin
vanjier16-Sep-13 1:31
vanjier16-Sep-13 1:31 
GeneralRe: need a coah for a WPF projet Pin
Pete O'Hanlon16-Sep-13 1:50
subeditorPete O'Hanlon16-Sep-13 1:50 
AnswerRe: need a coah for a WPF projet Pin
Abhinav S9-Sep-13 7:15
Abhinav S9-Sep-13 7:15 
QuestionVirtual classroom using silverlight Pin
Member 101834574-Sep-13 1:22
Member 101834574-Sep-13 1:22 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.