>>>>Could this be the sideeffect of the limitation of .valid(), .when() and the two spinner events, from which you can't call anything that shifts focus? Launching a form (or messagebox) makes the whole form to lose focus, but it's not an explicit .setfocus() to anything, so the runtime doesn't catch it as an error. But I'd guess instead of an error you get weird behavior like this.
>>>>So perhaps you just move the code from valid into something else, even into a one-time 5ms delayed timer?
>>>
>>>Definitely think it's about focus, but fwiw, the textbox's LostFocus does fire eventually. I actually think it may be the called from eating the rest of the click. I've tested in a base class form with base class controls, so I know it's not something in my classes anyway.
>>>
>>>Tamar
>>
>>In situations like this I've used an idea I got from a Drew Speedie session: issue the command from a "hand_grenade.prg" with a built-in timer after which the call (passed as a parameter) is executed. That way the processing be beyond the valid when the call actually fires.
>
>Exactly what I meant with "one-time 5ms delayed timer". On my last gig we used that trick a lot - whenever the context or timing issues were preventing the regular sequence of events from occurring, we'd issue such a delayed command with a 100ms delay, or longer in worst cases. The trouble there is the context, because an external prg knows nothing about thisform. So we had a delayedTimer class for exactly such things, and I think it was used often enough to be added as an object to the base form class. So that solved the matter of context, you could pass it a "thisform.bla.bla2.bla3.setfocus()" and it would work.

Ah, I missed your comment.

Ours is a prg, hand_grenade.prg, as we have have many classlibs and each has their own context.

Hank