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?
Cheers!
- Greg
Greg,
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
Jav
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 ...
"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.
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 ...?
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.
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?
Hi Rocky.
I have created a small SL application that reproduces the issue.
How can I get the source to you?
Cheers!
- Greg
Either attach it to a post, or email it to me at rocky at lhotka dot net.
Due to the attachment size I've sent it to you via YouSendIt.com.
Cheers!
- Greg
I believe the problem is solved with the code I've now checked into svn.
http://www.lhotka.net/cslacvs/viewvc.cgi/core/trunk/Source/Csla.Xaml/PropertyStatus.cs?view=markup
Can you give this a try and confirm?
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! :-(
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.
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.
Cheers!
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.
Greg,
Are you refreshing your Csla.xaml references by selecting the dll from Csla\bin again?
Jav
Greg,
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:
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