Subject BeforePost timing
Author Jason Wharton
I just got bit in one of my apps because of this code in the SysPost()
routine:

if CancelUnmodified and
not IsRetaining and
not Modified and
( State in [dssEdit, dssInsert] ) then
SysCancel
else
begin
SysBeforePost;


What this means is that when posting via CheckBrowseMode the BeforePost will
not fire and the edit state will be cancelled.

Where I got hurt was in code I called Edit explicitly and had other code
based on the expectation that the BeforePost event would surely get called.
But, because no other changes took place it was still able to be
auto-cancelled.

Here is what I would like to propose as a solution to this problem.

If in code or by clicking the button bar or whatever calls the Edit or
Insert method this will ensure that the BeforePost event will fire. But, if
you are in a control like a grid and tab or arrow in such a way that it
automatically goes into an edit state implicitly, then if nothing is changed
it will allow the auto-cancel without triggering the BeforePost event as it
currently does.

How does this sound?

I know it is work and a little extra complexity to maintain this but I think
it will be worth it.

Has anyone else been bit by this?

Thanks,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com