Disappearing PropertyStatus Controls

Disappearing PropertyStatus Controls

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

GregDobbs posted on Monday, July 26, 2010

Using the latest release of CSLA 4.0.

I've got a Silverlight Usercontrol bound to a CSLA ViewModel that allows a new user to register - basic stuff.

 The UserControl has two grids - one containing controls for data entry to register the new user (originally visible) and another grid that displays once the user has been registered successfully (originally hidden). The data entry grid is hidden once a user registers successfully and the confirmation grid is then shown - all through binding and VisibilityConverters.  Works great.

Once the user has registered successfully the second (confirmation) grid displays a button to allow another user to register. All that button does is call BeginRefresh("NewMember") on the ViewModel to create a new Member. As expected, once again the original grid is displayed since it's bound to the IsNew property on the Model and the confirmation grid is hidden.

With one problem - none of the PropertyStatus controls are now visible. All of the textboxes have the red border indicating that rules are broken (FirstNameRequired, etc) and the Silverlight tooltips on those controls display the appropriate broken rules.

But no PropertyStatus controls are visible.

Any ideas?


- Greg


Jav replied on Tuesday, July 27, 2010


You might want to look up Rocky's following blog - It may (or may not) be applicable to your issue. http://www.lhotka.net/weblog/default,month,2010-06.aspx


GregDobbs replied on Wednesday, July 28, 2010

Thanks for the reference, Jav.

I don't think that's the problem - I can't find a Valid property anywhere on my BO or its properties.

Very strange ...

RockfordLhotka replied on Wednesday, July 28, 2010

"Valid" isn't a property - it is the name of a visual state. PropertyStatus (before CSLA 4) had a visual state called 'Valid" - but Silverlight 4 now treats that as a kind of reserved state name and that's the problem.

So any control in SL4 that has a state named "Valid" will fail. That includes older PropertyStatus implementations from CSLA 3.x, since they target SL2 or SL3 where that's not a reserved state name.

GregDobbs replied on Thursday, July 29, 2010

Hi, Rocky.

I am using the latest version of the  CSLA 4 release - so, this problem should have been resolved, and not rearing its ugly head, right?

Otherwise - perhaps something got lost in a regression test ...?

Russ replied on Friday, July 30, 2010

Hi Rocky,

I too am using the lastest CSLA 4.0 and am encountering intermittant PropertyStatus visibility issues. Sometimes it is visible when it shouldn't be and sometimes it is invisible when it shouldn't be. Also, my project is a WPF application.

When the PropertyStatus is visible and it shouldn't be the object is Savable.

RockfordLhotka replied on Friday, July 30, 2010

I don't have a repro of the issue on the SL side. I have SL apps that are working fine, but none that are failing, which makes debugging a challenge.

I haven't tried to repro this on the WPF side, but the code is the same on both platforms.

So I suspect there's some logic issue where the control gets confused. Something I'm not encountering in my scenarios.

Can either of you create a small, isolated repro - including the manual steps required by the user to cause failure?

GregDobbs replied on Saturday, July 31, 2010

Hi Rocky.

I have created a small SL application that reproduces the issue.

How can I get the source to you?


- Greg

RockfordLhotka replied on Saturday, July 31, 2010

Either attach it to a post, or email it to me at rocky at lhotka dot net.

GregDobbs replied on Saturday, July 31, 2010

Due to the attachment size I've sent it to you via YouSendIt.com.


- Greg

RockfordLhotka replied on Wednesday, August 04, 2010

I believe the problem is solved with the code I've now checked into svn.


Can you give this a try and confirm?

GregDobbs replied on Wednesday, August 04, 2010

Hi Rocky.

I replaced the PropertyStatus.cs file with the file checked into svn and rebuilt CSLA then re-ran my test project.

Unfortunately the problem still manifests - same as before.

Back to the drawing board! :-(

RockfordLhotka replied on Wednesday, August 04, 2010

OK, I see the difference - you are referencing via Path=Model.Property and my test (that I thought duplicated yours) does Path=Property.

So my fix fixed roughly half the problem.

Try the now-current code please - I think I got the whole problem solved now.

GregDobbs replied on Wednesday, August 04, 2010

This one's turning into an ogre ... still seeing the same problem in my test solution with revision 4955.

I'll try poking around - my C#'s not so good though.


RockfordLhotka replied on Thursday, August 05, 2010

It would be easy to fix if I abandoned some of the optimization code I added a while back - but I really don't want to do that except as a last resort.

I'm really surprised that this latest change didn't fix the issue - I replicated your scenario (I think) exactly and was able to get a repro and then fix it.

Your sample app requires more setup that I have had time for - it requires some hookup into IIS that I don't know how to do off the top of my head. So I've been reading your XAML and creating the same basic scenario in my test app.

Jav replied on Thursday, August 05, 2010


Are you refreshing your Csla.xaml references by selecting the dll from Csla\bin again?


RockfordLhotka replied on Thursday, August 05, 2010


If you can, try setting  a breakpoint in the SetSource() method of PropertyStatus. That's the method I've been focusing on, because the problem is that the control wasn't detecting when the data source changed in a couple scenarios.

Specifically, it was able to see the data source changing if the binding changed - but that wasn't enough.

So I made it also detect that the DataContext changed - which solved one scenario (the Path=property scenario).

But your XAML was Path=Model.property so neither the binding or DataContext change - it is the lower-level Model property that is changing. So my latest change was to implement logic like this:

Rebind to the source if:

  1. The binding is different
  2. The DataContext is different
  3. The SetSource() method was called and the bound property value didn't change (which means something else changed - almost certainly the source object)

In my test apps (SL and WPF) this latest change works with the Path=property and Path=Model.property scenarios.

Somehow there must be some subtle difference in your code that isn't obvious from the XAML.

If you can put a breakpoint in SetSource() you can step through the first 4 lines or so - up to the if statement that checks the conditions I just listed - then you can maybe see why it isn't rebinding to the source in your particular case.

Copyright (c) Marimer LLC