>>You may be calling the click from inside an OCX control or beyond the container. Little location issues can really eat the clock! Here's hhat ya do in your code attempting to click your button:
>>thisform.container.CmdButton.Setfocus()
>>keyboard '{SPACE}'
>>
>>Get it ?:)
>
>Calling a button's click is bad enough, keyboarding is a kludge of a much higher level...

I agree - you should see it when I borrow a listview node's checkbox click method to fire a a treeview itemclick on another form. It is possible to go way beyond the the obvious kludge of a mere button click - you just need to find the reason.

My button click methods are external (in a procedure file), but somethimes, like some situations when an ocx toolbar button is clicked, the app will just fall through to the "read events" - the only way to fire it is to focus a control and "space" it. Don't know why. And I don't [even] wonder much about it would mean even if I understood why!:-)

There's this one little pita quirk i am trying to predict (or at least do some rudimentary science on!). Sometimes, when a textbox (it may have data or a null assigned through its value property) receives focus - usually a mouse click - the cursor just goes lala - not to be seen until some other action frees up whatever cog was stuck!

My favorite helpful response work around was when I responded to a message with fancy smancy kernal function calls to get the screens pixel dimensions (it was GetDisplayMetrics - i think). Fortunately, somebody who could claim to be conscious saved the question guy from my blinded-by-the-light-need-to-help , and reminded us of the SYSMETRIC() VFP function.

It was a real "Lucy" moment - wait - what's that? - there's something in the air - aaaaah - it's mother soft's scheduled pheromone release - time to take my equalibrium!