Nov 16, 2010 at 7:51 PM
Edited Nov 18, 2010 at 5:41 AM
That is very odd. I can set NonSharedViewModel or SharedViewModel in my UserControls and in the relating ViewModel I do the ExportViewModel, but when I switch between my contentcontrol templates
my LessonPlannerViewModel is always called and the other viewmodels too. Although I use SharedViewModel...
But what would mostly interest me is the scenario with my UserControl containing 6 other UserControls. all have ONE ViewModel as DataContext. Can you comment to that?
Do you have a private email where I can send you my project and hope it is in good hands?
EDIT: This is even more odd. I have now replaced ALL "NonSharedViewModel" in my project with "SharedViewModel" and only the View`s are recreated now.
But the visual state of a datagrid with an selecteditem is lost when I switch between my templated contentcontrol and the viewmodels. I have made the selecteditem
with a Mode=Twoway so the state should actually be saved in the ViewModel, thats odd.
oh this is really a mess. Can`t wait for your answer...
EDIT 2: So SharedViewModel means my visual state is saved (having Mode=TwoWay on my bindings of course) because the ViewModel is created only once ?
Why would it make sense to use a ViewModel locator where I use NonSharedViewModel ? I always thought the static resources are the best to prevent the recreating of the VM.
I have studied your wpf demo sample and I see a big difference in the way you use MVVM to what (Jeremy Likeness - sorry that name was wrong) Colin Blair ( last post -
http://betaforums.silverlight.net/forums/p/157070/351292.aspx ) said. Colin Blair would also use 2 Views:
SelectedUser and UsersScreen BUT with ONE ViewModel holding the CurrentEntity to switch the master/detail.
YOU use 2 ViewModels... woah people use MVVM so differently everytime I read another blog thats so frustrating...
It seems every alpha geek has its own interpretation of MVVM.
EDIT 3: I checked your mediator and I like it more than the messenger from mvvm light toolkit. Because I do not have to wrap value types which show no meaning sending them in an extra custom class.
With your mediator I can use a string just like in CAB. Even the annotation: [MediatorMessageSink(MediatorMessages.SelectedUser, ParameterType=typeof(User))]
is very similar to CAB. Instead of CommandNames.XXX you wrote MediatorMessages.XXX both string constants hehe.