Hi,
I appreciate that this topic has probably been done to death, having spent the last few hours reading as many threads as I could find, but I wanted to check that the following is expected behaviour.
When using the ProjectEdit form within PTracker I find that the Cancel functionality works fine if data is only changed in the grid, and nowhere else.
However, if data is changed in the grid and then further changes are immediately made in the detail area then Cancel does not undo the changes in the grid.
I am very much a newbie on all this, and so wanted to check what the expectation should be. Further, what should the technique be, using PTracker as the example, to ensure changes to both the grid and data area are rolled back.
Many thanks,
Steve
It is possible that PTracker is a bit out of date, though I've tried to keep updating it as we've all discovered the various solutions to get data binding working.
As you've probably discovered, there are some Windows Forms bugs that can cause you issues, several of which have hotfixes you can get from Microsoft.
But it is also the case that it can be tricky to get the various BeginEdit/CancelEdit/EndEdit calls correct, due to the way data binding automatically calls them and the way you may want to call them yourself.
It should be the case that data binding will call BeginEdit on your root object automatically when binding occurs. It will also call BeginEdit on the active row (object) in any grid.
To properly implement a Cancel button you need to call CancelEdit first on the child bindingsource object, then on the root bindingsource object. Not on the business objects themselves.
However, I recently discovered some issues with the grid, where having focus leave the grid causes data binding to call EndEdit on the child bindingsource, which can be quite awkward in some scenarios. This problem does not occur if your Cancel button is in a ToolStrip, because then focus doesn't leave the grid when the button is clicked...
My recommendation is to do what I've been doing, and create a very simple parent-child object model (I don't even bother with data access - just the properties) and get your UI working against that model. There are so many variations on how you might construct your UI and what controls you might use that it is hard to generalize, but this approach at least allows you to rapidly and (relativley) easily troubleshoot the interaction between data binding and your objects. Then you can translate your model into a bigger app.
Rocky,
Thanks for the advice and it is, of course, what I have been trying but with little success. I guess I was hoping that someone might be able to explain and provide a ready-to-use "remedy" to this particular scenario.
I've spent several hours today trawling through the forum and come across the items to which you refer. So, yes, I have been using bindingsource objects.
With regard to lost focus, the grid control appears to work fine if data in the detail controls aren't changed, but merely receive the focus. It seems to be when the detail control data is changed that something different happens.
I'm actually trying to use the Infragistic controls, which in respect of this thread at least, exhibits the same behaviour as the MS DataGridView.
While writing this I've just tried calling CancelEdit (within my Infragistic based application) on the child bindingsource before (as you say in your response) the root bindingsource and it works. I had the calls the other way round. I'll give it a try on the PTracker app next.
I guess for now this thread is closed.
Many, many thanks.
Steve
Just wanted to add a postscript.
Calling CancelEdit on the child bindingsource before the root bindingsource appears to work for the Infragistic grid I'm using, but this approach doesn't seem to work for PTracker.
Rocky, I would also like to add my thanks for your excellent work and amazing attention to detail. I hope you are well on the way to recovery.
Steve
Copyright (c) Marimer LLC