DataContext declaration in xaml using CM

Topics: Conventions, Getting Started
Nov 8, 2013 at 2:42 PM
Edited Nov 8, 2013 at 2:55 PM
As I understand I'm not even supposed to initialize the DataContext in XAML explicitly when using Caliburn.Micro to make bindings work properly.

But if I will not, then the standard parser will say that the bindings are invalid as far as we can't rely on conventions in all situations.

How to set up DataContext properly using View-Model first approach with Caliburn.Micro?
And by the way, what strategies do we have to work with DataContext at all and when we set up design-time bindings particularly?

p.s. The problem is that I have faced a situation when bindings in the view fires up only once. I have fixed this by instantiating the DataContext in a code behind (code smell, I know).
<UserControl.Resources>
    <vm:ViewModel x:Key="ViewModel"/>
</UserControl.Resources>

<TextBox Text="{Binding Source={StaticResource ViewModel}, Path=PropPath}" />
Such an approach was a reason of why bindings fired up only once (in a real code there were more complicated bindings). As I understand, such an approach, by the way, leads to creation of the additional ViewModel (because the very first ViewModel will be already instantiated before a constructor in XAML will be invoked), am I right?
Nov 8, 2013 at 4:44 PM
This is news to me, but I'm a complete novice at this. I had a UserControl working with a DataContext, then tried to put that control in a MUI page and the data doesn't get initialized. I will want to get into Caliburn.Micro, so I'm interested to know what's the proper fashion to hook up the data as well.
Nov 8, 2013 at 4:49 PM
ViewModel first or you want View-First because what you have here is View-First. As with all things you do what ever works for you. The binding of View-First is slightly different with CM than with ViewModel first which it really excels at.

https://caliburnmicro.codeplex.com/SourceControl/latest#samples/Caliburn.Micro.ViewFirst/Caliburn.Micro.ViewFirst/ShellView.xaml

Your snippet being very generic will work but you would have to instantiate the view in codebehind or Caliburn.Micro way to affix the cal:Model.Bind = "ViewName" to the view in question the viewlocator will then find the viewmodel to attach.

Can you explain the Datacontext binding issue you are experiencing? Don't think I have ever seen an issue where something firing was an issue. Not having PropertyChangedBase or the screen as an inherited base could contribute to your issues.

Code samples from a project or small snippets help.
Nov 11, 2013 at 4:32 AM
Edited Nov 11, 2013 at 4:33 AM
Yes, indeed, double ViewModel instantiation somehow damaged the bindings in the View!

So, the upshot is:

If you use ViewModel-first approach THEN YOU SHOULD NEVER INSTANTIATE THE VIEWMODEL BY YOUR OWN! All you need is to satisfy the naming conventions! And that's all.

If you want the design-time support, then just add
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:cal="clr-namespace:Caliburn.Micro;assembly=Caliburn.Micro"
        xmlns:viewModels="clr-namespace:YourVMsNamespace;assembly=YourVMsDLL"
        mc:Ignorable="d"  d:DataContext="{d:DesignInstance Type=viewModels:DestinationChoiceViewModel, IsDesignTimeCreatable=True}"
        cal:Bind.AtDesignTime="True"
Whwn you want to set a binding for something like ListBox and to use DataTemplate inside, then explicitly set ItemsSource to whatever property you need and you'll avoid standard xaml parsing comlains about resolving the bindings in a DataTemplate.
Nov 12, 2013 at 3:19 AM
so all figured out, no more binding issues or refreshing issues?
Nov 12, 2013 at 3:51 AM
No more issues. The reason of the bindings breakage is that the properties were binded to the properties of the ViewModel which I have instantiated in a Window.Resources, but CM set up bindings before Window.Resources occures. Doing so I did can cause unpredictable behavior in a theory (and in practice, as we saw), because of instantiation of extra (needless, redundant) ViewModels.