I do see the issue you are talking about. That's unfortunate!
While you didn't see an issue in 2.x, it was there behind the scenes because the edit levels were getting slowly messed up as you moved through the grid controls. 3.0 is just making you aware of the problem.
However, I think it is a bug in 3.0, because clearly this is not desired behavior, and this scenario should work transparently.
Unfortunately the fix is a bear. Not for me so much maybe, but because it could have some backward compatibility impacts.
The fix, as I see it, is to prevent n-level undo from cascading calls to child collections/objects when the undo behavior is invoked through IEditableObject. The DataSet, you see, doesn't cascade anything. Each DataTable, and really each DataRow, is entirely independant - they don't work together to manage their states. And the BindingSource data binding model is designed around the DataSet, first and foremost.
So (and I've been resisting this for years), I think I'll have to cripple n-level undo in the case where it is invoked through IEditableObject ![Sad [:(]](/emoticons/emotion-6.gif)
Doing this isn't easy, but I think it is possible. However, there's a backward compat issue, for people who were using a mixed-model of calling n-level undo manually and using IEditableObject through data binding. I'm not certain I can reconcile the use of both models at once, which could entirely block some people.
But I need to give this more thought yet. As with all things around n-level undo, the complexity is very high.
Time to talk the dog for a nice long walk so I can think about this.
It is amazing how taking a walk can help. I think I have it, and without too many side-effects.
I didn't ask which language you are using, but I checked in a possible fix in the C# code. So if you would like to test this, grab the UndoableBase and BusinessBase classes from Csla\Core from the svn repository and use them to update your 3.0.1 code.
The change solved the issue with my test that replicated your issue. And it didn't break PTWin. But more testing is still needed to ensure that there aren't ugly side-effects.
It is still the case that mixing modes (IEditableObject and manual calls in a single Windows form) may have issues. If anyone is doing that please let me know on this thread so we can work to see if this change causes you issues!
I've been unable to find any issues with the change, so I applied the changed to VB as well and put a 3.0.2 test release on the downloads page (www.lhotka.net/cslanet/download.aspx) to make it easier for people to try.
If you do any Windows Forms development with data binding, and are using 3.0, please, please, please give 3.0.2 a try to see if it causes you issues!! I'd rather know about issues ahead of time than after the fact.
Again, my unit tests and my test apps work - including the parent-child-granchild test that was broke before this change - so I think life is good.
dagware:
Rocky -
PS: Completely off topic, do you know why Firefox's automatic spell checker doesn't work when typing these messages? Is this some odd sort of control that Firefox doesn't know about? And if so, is there any reason it can't be changed to something Firefox knows about? If you don't have the time or inclination to respond, that's cool with me. I was just wondering, since I'm not the world's best speller, and I love it when Firefox tells me of spelling errors as I type.
I haven't a clue, sorry. I think that Community Server uses FreeTextBox, and maybe Firefox has some issues with the way FTB does what it does.
I do have the license to upgrade CS to the latest version, and when I get around to doing that perhaps it will use a newer version of FTB, or some other editing control.
Copyright (c) Marimer LLC