CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • CSLA 4.1 PropertyStatus Misbehaving in Silverlight App

    rated by 0 users
    Answered (Verified) This post has 1 verified answer | 5 Replies | 3 Followers

    Top 500 Contributor
    28 Posts
    trives posted on Fri, Nov 4 2011 11:21 AM

    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.

    Answered (Verified) Verified Answer

    Top 10 Contributor
    2,279 Posts
    Verified by trives

    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.

    Jonny Bekkum, Norway CslaContrib Coordinator

    All Replies

    Top 10 Contributor
    2,279 Posts
    Verified by trives

    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.

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 500 Contributor
    28 Posts

    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.

    Top 10 Contributor
    2,279 Posts

    The control registers MyDataContext as a dependency property from DataContextChanged.

    Read more about it here:

    http://msmvps.com/blogs/theproblemsolver/archive/2008/12/29/how-to-know-when-the-datacontext-changed-in-your-control.aspx

     

     

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 500 Contributor
    28 Posts

    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.

    Top 10 Contributor
    9,475 Posts

    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 :)

    Rocky

    Page 1 of 1 (6 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems