David,

I did in fact have an object SetFocus() in the forms parent class that did just as you described. I got rid of it and now all the menus are good except that the keys are not always recconized. The menu options work, but the menu key doesn't always work. Oh well, if this stuff was easy everyone would be doing it!

Gary


>Hi Gary,
>It's only the code that makes the form visible prematurely that matters.
>For example if you do an object.setfocus() in the init and trace it, you'll see the form become visible before time, that then affects the menu's modality interaction. The menu will run but will be disabled.
>We have hundreds of complex forms running with menus. We have a form class upon which all others are based in which we have the menu name (or list of menus) as a property of the form.
>We have a navigation object on each form, again in the base class, which Bindevents() menu running to the gotfocus() and coordinates the toolbar with the menu and the form. (sounds pretty complex eh?)
>Anyway good luck with it.
>
>
>
>>David,
>>This will tougher than I thought. I have a lot of code running before and during the form init(), walking the control collections, etc.
>>
>>One thing to note is that as soon as I close one modal form, the menus for any other open modal forms are active. IOW, if I launch a form from a form or toolbar and launch a form from that one and so on, the newest active form has a disabled menu but as soon as I close that form the menu is active for all the rest. Some odd interaction here. Thanks for the reply.
>>
>>Gary
>>
>>
>>
>>>Hi Gary,
>>>You need to ensure that the form is not forced to be visible during the init, activate and gotfocus events. That is if you have any code that does
>>>object.setfocus()
>>>object.visible= .t. etc
>>>while the form is stabilising will ruin it all for you. Even a wait window might kill it.
>>>
>>>Your gotfocus() method should simply have
>>>

DO Mymenu.mpr

>>>
>>>If you get stuck send me an email and I'll forward an example to you
>>>
>>>Regards
>>>
>>>
>>>>David,
>>>>I've gotten into this now and the menu is not enabled at first. I know that the GotFocus() is firing because I put a wait window nowait that displays, but the menu is disabled. If I set focus to another form, debug etc., GotFocus() fires again on return and now the menu is enabled. Does this ring any bells? Thanks.
>>>>
>>>>Gary
>>>>
>>>>
>>>>>>Hi,
>>>>>>I need to provide my users with some navigation keys that can be used on modal forms. ON KEY LABEL works a little TOO well. For example, I use the PGDN key to move between records on some forms. Sometimes a fair amount of code is run here, doing lookups on other tables, etc. If the user has quick fingers, the PGDN will run code that hasn't finished running giving some confusing results to the user. I'd like to use the menu for these key assignments thinking that repeated key strokes would que up rather than firing instantly, but the modal form disables the menu options.
>>>>>>
>>>>>>Many thanks for any suggestions.
>>>>>>
>>>>>>Gary
>>>>>
>>>>>You could consider using menus with the modal forms. They do work if you call them in the form.gotfocus() event.
>>>>>eg.
>>>>>Myform.gotfocus()
>>>>>Do Myform.mpr
>>>>>
>>>>>So your menus can then have the normal hotkey assignments avoiding ON KEY LABELS completely. You do need to ensure that your form does fire the gotfocus method, ie there should be at least one control on the form which can receive the focus.