If you have a copy of SPY++ (bundled with versions of VS) then you can use that to watch the activity (windows event messages) are being tossed around for your report form or the menu...I would guess that the menu is the window to watch messages for. However, that seems a bit extreme to start out with. I mean you could find out what message is reenabling the access keys for you menu, but I'd start with the report form and listener class and work on it from that angle first.

Try a little battleship, (I see you have already)... but what does using "NOWAIT" clause in your Report Form do? Does it change the behavior? When exactly does the menu stop responding (you can step through the report in VFP 9 to debug with a little effort)? What event(s) fire just prior to the keyboard events coming back (vfp debug event tracking should give you a clue or two)? Is it just this third-party toolbar or do the VFP base toolbars exhibit the unwanted behavior? Right now I have more questions than answers I'm afraid, but for me understanding why something does what it does is the first step... then if it still won't behave hit it with a sledgehammer.

>I'm using a 3rd party toolbar component that loses access keyboard events when I REPORT FORM in a top level form. The workaround - to restore access to keyboard events - is to Alt+Tab to another application and then back to my application. This restores my 3rd party toolbar's ability to recognize keyboard events. I can also restore keyboard events by using the mouse to resize my top level form.
>
>Any suggestions on an API call that would accomplish the same effect as either of these techniques?
>
>Thanks!
>Malcolm