>>Just a wild geese ... guess :). The event of grid.deleted() fires upon deletion, right? And the method you write there is supposed to handle it, therefore you may use it to prohibit deletion or do whatever you want when the bloody little square is clicked on, therefore I conclude it fires _before_ the record actually gets deleted. A simple thing I'd try (if I didn't have tons of my own things to try already) should be to
>>
>>dodefault()
>>do_my_code_here
>>nodefault
>>
>>in the grid.deleted() code. Its default behavior is to delete (or restore) the record, so just let it do it first.
>>Did I guess right?
>
>When I first encountered this situation, this was my first guess too, but alas, twasn't to be. The only solution I've come up with is pretty much the same as John's.

Erik:

Dragan is fairly correct in that this is the behaviour I observe. However, to overcome the problems, I have had to eliminate the delete column and add a delete button. When you click the little delete square, the deleted() method fires, but the actual delete of the record does not occur until after the method completes. I have tried DoDefault(), etc., including deleting the record number passed to the method. What then shows on the grid, when I issue a delete, are 2 deleted records -- the one I deleted and the next or previous record. The behaviour is totally unpredictable (at least to me).

However, I did not use Dragan's exact suggestion, which I will try (I left off the nodefault at the end):

dodefault()
do_my_code_here
nodefault