when i was researching my menu problem on UT, many people gave me suggestions for _screen menus. obviously i never tried them, since i was using an sdi. but the two most often suggestions were activate and then push/pop.

push menu _msysmenu
pop menu _msysmenu

activate menu _msysmeu nowait

worth a try - brenda.

>Thanks Brenda,

>I checked out the article and it seems to be specific to Top-level forms, which >I'm not using...

>Larry

>>>The menu is disabled when my browse form fist opens. But if I press ENTER to open an edit window, then immediately close the edit window, the menu is enabled (?)

>>>The menu is created in a custom method "oBrowseForm.InitTBMenu". This is called from the PAINT method (per a previous suggestion on the UT) like this:

>>> *-------------------------------------------------
>>> PROCEDURE PAINT
>>> IF ! THISFORM.lMenuDone
>>> SET SYSMENU TO
>>> THISFORM.InitTBMenu
>>> ENDIF
>>> ENDPROC

>>>The edit window SETs MENU TO because I don't need Add / Change / Delete in Edit mode. When control passes back to the browse form, lMenuDone is set to .F. and the menu is re-created... THIS TIME IS ENABLED?????

>>are you using an SDI toplevelform (not _screen?). if you are using an SDI you might want to look at msn kb article q171570. i had trouble with my menu in an SDI form. my problem (and what the kb article discusses) was specific to the menu not refreshing properly based on the SKIP FOR values.
>>
>>if you think the q171570 applies to your situation, give me a reply back and i will tell you how i found a workaround.
>>
>>brenda