>Yes it definately sounds like we're doing the same thing. So you can't figure it out either?

Nope. When this happened to me I posted the following statement:

>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?

Jim Nelson then offered the following:

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.


We're agreeable on what appears to be happening but I'm still really not sure as to why. Maybe you can offer more to mine and Jim's statements? HTH