>I also figured out why I never see this behavior... in any action that I perform in a grid, the SetFocus is the last thing I code. So inthe click event of a button, if I
>SELECT whatever
>DELETE
>THISFORM.mygrid1.Refresh()
>THISFORM.MyGrid1.SetFocus

The problem is that my call to SetFocus occurs way down in the innards of my form class, after cancelling an edit. Only then do I take the additional step (in the form itself) of resetting the work area. What I think I'll do is override the form class's SetFocusToFirstField (which was the "culprit") to do nothing in this case, and call the SetFocus afterwards as you do.

Although...I wonder if there is some way to force that SetFocus call to change the work area immediately? DoEvents()?

>While the inconsitency is annoying, remembering its presence and avoiding the situation looks like enough of a workaround.

I'm hopeful I can work around it. I really don't want to fully qualify all my record-oriented commands. It might be a good idea for the reasons you mentioned before, but really, I didn't have any trouble with assuming a given work area stayed constant until I got into grids. Plus, I got an app I gotta get out! :)

I learned two things: 1) focusing a grid selects its table, and 2) focusing a grid doesn't select its table _right away_. :)