Rick, did you ever find a solution to your problem?

Just for the record, after further experimentation with a hotkey object, I found that some Alt key combinations are passed to the keypress event while others aren't. I haven't quite figured out all the reasons why (menu pads shortcut keys are one). Same goes for Ctrl combinations that are defined as keyboard shortcuts for menu items.

If it wasn't part of Microsoft's plan to allow us to trap any key combinations, they should have at least documented the exceptions. If their goal was to allow us to: a) Trap some of the keys all of the time, b) trap all the keys some of the time, but never all of the keys, all of the time...then I do believe they've succeeded. What's that wishlist address?

>The form recieves all keypress events except alt if my memory serves. As long as you have keypreview=.t. in the form. I've done this before. As for the overhead, it could be reduced by filtering the keys you pass on to the object:
>

>LPARAMETERS nKeyCode, nShiftAltCtrl
>if between(nKeyCode, 1, 26) && CTRL-A thru CTRL-Z
>	thisform.hotkey.(nKeyCode)
>	nodefault
>endif
>

>>>Just a thought... how about creating a "HotKey" object that your form class keypress events pass the value of all, or a certain range of keystroke values to?
>>
>>Nah, that doesn't work because the form doesn't receive all keypress
>>events. It only receives ALT keys, otherwise keypress events go to
>>the individual controls. Even if it did work there'd be too much
>>overhead to check each character. Lots of typing going on in this
>>app.