I'm using CSLA 4.1 in a Silverlight application and am having issues with the PropertyStatus control. In my XAML, I have markup like this:
<CheckBox IsEnabled="{Binding CanWrite, ElementName=DisplayFullNamePropertyStatus}" />
<csla:PropertyStatus Visibility="Collapsed" x:Name="DisplayFullNamePropertyStatus" Property="{Binding Model.FormatOptions.DisplayFullName}" />
I'm using ViewModelBase where the Model can change from one customer to the next customer.
What happens is that the PropertyStatus does not update its state (e.g. doesn't update CanWrite) when the model changes. I tracked this down to code in PropertyStatus.SetSource that only updates the state if either the PropertyStatus.Property binding expression changes, the PropertyStatus DataContext changes, or the property value changes. In the XAML above, the binding expression is the same, the DataContext (i.e. the ViewModel) is the same, and the property value is the same for both business objects. What's not the same, though, is the value for CanWriteProperty(DisplayFullNameProperty).
Anyway, I noticed that the latest version of PropertyStatus (revision 5230) seems to have addressed this issue, and it seems to be backwards compatible with 4.1 from my limited testing so far. One question I have is whether anyone knows a reason why it wouldn't be backwards compatible.
A second question I have relates to the MyDataContext property in the SILVERLIGHT preprocessor directive. The link referenced in the comments mentions the need for a SetBinding statement to bind MyDataContext with the actual DataContext of the control. I don't see such a statement in PropertyStatus. Am I missing something?
Thanks.
Hi,
1. The latest version is backward compatible for 4.x. There is no new Inferfaces or events to hook into.
2. I haven't used the MyDataContext so can't help you on that.
Thanks for the reply JonnyBee.
I think I might not have been clear with respect to the second question.
In the PropertyStatus constructor, there is WPF-only (!SILVERLIGHT) code that establishes a handler for the DataContextChanged event that calls SetSource if the control is not loading. Starting on line 336 in PropertyStatus, there is Silverlight-only code that defines MyDataContextProperty and MyDataContextPropertyChanged static method, which calls SetSource in a similar fashion to the DataContextChanged handler for WPF. It appears that this Silverlight-only code is attempting to do the same thing as the WPF DataContextChanged handler but for a Silverlight context since Silverlight doesn't expose a DataContextChanged event.
My question is how does the Silverlight code work without a SetBinding statement to bind MyDataContextProperty to the real DataContext inherited from Framework.DataContext? Or, for some reason, is it not necessary in Silverlight to have this workaround to simulate a DataContextChanged event?
Based on the entries in the code repository, this code was added in revision 5200.
The control registers MyDataContext as a dependency property from DataContextChanged.
Read more about it here:
I've used this technique a lot in our Silverlight application. I was only trying to point out that PropertyStatus (at least revision 5230 in /core/trunk/source/csla.xaml) is missing the SetBinding statement:
SetBinding(MyDataContextProperty, new Binding());
which normally goes in the constructor. Just registering a dependency property won't do too much without also establishing a binding between the dependency property and the underlying DataContext.
I wasn't sure if there was some other way you were binding to the real DataContext.
Anyway, even without establishing the binding, the latest version of PropertyStatus seems to work fine.
Thanks for the replies.
It has been a while, but I think someone (either me or Justin?) figured out a clever alternative solution.
None of it matters for long anyway, because Silverlight 5 finally has a data context changed event :)
Copyright (c) Marimer LLC