Hi,
I've been using CSLA v2.1.4, v3.5 (preview 080115) and now
v3.5 Beta 1.
I've said this before but I love this framework.
First the "bad UI behavior". This occurs in ALL 3 versions above.
Try this:
1) Log in as power in PTWin
2) Edit 1 or more Projects and /or Resources (leave them open so they appear in Documents Drop Down)
3) Edit Roles
4) Logout
5) The PROBLEM (bad UI behavior): after the "edit roles" document closes the document left on the foreground is STILL editable. On the other hand, all other documents (if any) are greyed out and read-only.
6) In v2.1.4 and in v3.5 preview, if you try and edit a field you will get the error provider message "Property Set Not Allowed" and the change will be rolled back as soon as you change focus from the textbox. In addition, you may cancel or close that "editable" document.
This leads me to the bug found in v3.5 beta 1 only:
If you perform the first 5 steps above and then change one of the fields of the "editable document" you still get a "Property Set Not Allowed" but with NO ROLLBACK of change. Furthermore, the application does not allow you to change focus nor can you close or cancel in any open document.
You can open more documents but can't close them.
The only way out of this is: Log back in as power!!!
Is there a Fix for this bug?
Either, we should not have an "editable document" open when logging out or if we do insist on this have any changes to that document rolled back (effectively making it read-only).
Also, how to change the UI's bad behavior of leaving the foreground document editable after you log out from the "Edit Roles" document item?
Trying to do my part of this wonderful framework...
Thank you,
Emmanuel.
This is why I hate UI development. Really, I find it to be all piddly little stuff and never fun... I know, people love it, and I respect those that enjoy it, but I just find that I'm always fighting with the stupid UI technologies...
Which explains why I'm a middle-layer framework guy ![Wink [;)]](/emoticons/emotion-5.gif)
The "being stuck on a field" problem is because the object throws an exception when someone tries to set a property. This is normal Windows data binding behavior - if an exception is thrown from a property set block it traps the user on that field. So this is expected behavior - and I would have expected it to occur in earlier versions of CSLA as well, because it isn't really a CSLA issue - it is a data binding issue. But maybe Microsoft changed something in Windows Forms 3.0a, that's quite possible.
The real issue is that the UI should have greyed out, so as to prevent the user from trying to enter values into the controls - thus preventing the property set block from being called. So we're back to fighting with UI issues...
I have resisted (and will continue to resist) writing an actual UI framework. PTWin has just enough plumbing to limp by - which is fine, because my focus isn't on the app as a whole, but rather on each individual form and how data binding works within that form.
The easiest solution might be to drop the Document menu entirely and make the app only ever show one document at a time, and that may be what I do in the end.
RockfordLhotka:
This is why I hate UI development. Really, I find it to be all piddly little stuff and never fun... I know, people love it, and I respect those that enjoy it, but I just find that I'm always fighting with the stupid UI technologies...
Which explains why I'm a middle-layer framework guy
Don't hold back, Rocky - tell us how you really feel. ![Stick out tongue [:P]](/emoticons/emotion-4.gif)
It is a foreach iterator issue.
When the principal changes there's a foreach to loop through all documents and notify them that the principal has changed.
But the RolesEdit form closes itself, which means it is removed from the list. You can never change a list during a foreach process without getting unpredictable results - and that's what is happening here.
The fix is to change that top-level foreach to make a copy of the list first, then loop through the copy of the list. That turns out to be harder than it should be because the ControlsCollection type doesn't seem to support LINQ queries... Here's the replacement code in MainForm.DoLogin()
// notify all documentsI've now also changed ProjectEdit and ResourceEdit to do a cancel operation if the new principal isn't authorized to edit the object. This brings the WinForms behavior in line with WPF, and is a better user experience in my view.
You can never change a list during a foreach process without getting unpredictable results - and that's what is happening here.
When I run into this issue I switch the iterator to use the integer index and then loop backwards over the collection to modify (or remove) items from the list. Not sure if that would apply in this case though.
Joe
I usually do to - and have elsewhere in CSLA. That might work here, but I'm not entirely sure, because I really don't know what a child form might do in response to that method call. It might disable itself or close itself like the forms in PTWin. But it might do other things I haven't thought of.
Copying the list is comparatively expensive, but is ultimately safe (I know all forms will get notified). And the expense is pretty meaningless because this only happens when a user logs in or out - and that isn't something that happens many times a second/minute or probably even an hour.
Copyright (c) Marimer LLC