>----- Snippage
>>
>>Using row buffering the toolbar revert button worked because a toolbar can never receive focus but the menu pad didn't because something behind the scenes is issuing an automatic TABLEUPDATE() between control going from the form and the menu. Is this statement generally true? Does anyone have anything to add or can explain the why's and wherefore's of why this happens?
>
>Colin,
>
>I think I could make sense out of that statement, using some 'reverse' logic. . .
>
>As we learn from the TasTrade example and its ToolBar (or maybe it was elsewhere), a ToolBar never actually removes focus from where you last were (so you typically have to have special code to detect and programatically change focus in the case that you may have been editing a entry field to cause the Valid to execute) or execute the Valid code from there). Whtih everything else (including clicks to menus) this is *NOT* the case - valids execute because focus is moved.
>Anytime you move the focus off of a record field and to something else I assume you are (intrinsically) moving the record pointer. With record buffering, this results in a TABLEUPDATE(), but not with table buffering.
>
>Something along those lines feels right to me.
>
>Cheers,
>Jim N

Seems so. I've been bitten on both ends of this situation now. It seems that, IMHO, the best approach when combining this functionality together is to go with table buffering and as you mentioned to have extra code to handle situations like TABLEUPDATE(). I use code that follows the general logic of the following for this:

_SCREEN.ActiveForm.ActiveControl.SetFocus (thanks to Jim Booth for this hint)

Thanks for the reply. Unless we're both wrong I have some confirmation that my assumtions are sound.

Cheers