CSLA 3.8.x PropertyStatus Misbehaving in WPF App [EDIT: Workaround found!]

CSLA 3.8.x PropertyStatus Misbehaving in WPF App [EDIT: Workaround found!]

Old forum URL: forums.lhotka.net/forums/t/11909.aspx


stefan posted on Thursday, March 28, 2013

Hi,

in my WPF app (csla3.8.x compiled under .NET4 and Bxf)  I experience the following:

An editable root object is edited and then saved (view stays open), then the user can trigger a status change to the object by clicking a 'Publish'-button. This invokes a DocumentPublisher-command that processes the object on the serverside, and returns an updated object, which then behaves like a read-only object, because CanWriteProperty checks the new status first...

After I set the Model property in the ViewModel to the updated new instance of the object, quite a lot of the PropertyStatus controls in the view don't update and stay databound to the old instance of the business object, resulting in many controls still being in edit mode, when the underlying databound properties have become readonly by the time. The controls that don't react correctly to the DataContextChanged event are always the same ones...

In this specific case, I followed the ProjectGetter pattern from the ProjectTracker sample app, where I have two different ViewModel objects. Could it be that this somehow confuses the SetSource method in PropertyStatus?

Any help is appreciated!

<edit> I found a Workaround:

As an intermediate step, setting Model=null right before setting it to the new instance, solves the issue so that all PropertyStatus controls refresh their bindings correctly!

This still is a hack - the PropertyStatus control in 3.8.x still appears buggy to me...

</edit>

RockfordLhotka replied on Tuesday, April 02, 2013

As long as there is a workaround we won't fix bugs in 3.8. That is two versions behind current, and so will only be changed in cases of extreme bugs with no workaround.

Copyright (c) Marimer LLC