VERSIONS: All (?), written for Paradox 5
SUBJECT: Who gets the menuaction?
BY: ADRIAN FOWLE and MARK PAUKER
QUESTION:
Who gets the MenuAction invoked, when I do the following:
- I open a form, which creates a menu (including popups)
- The form has a "dialog" window style with no control menu or resizable frame. (I don't want the user to close it)
- I close the Folder so my form is the only one open
The menu appears, but when I click on it the form I wrote loses focus, and so does not process the menu choice. Who (if anyone) is getting the
MenuAction method invoked?
FROM: MARK PAUKER
Dialog windows cannot have menus. Thus when you click on the menu bar, Paradox will activate the topmost non-dialog window, and all
menu events will be sent there. (As far as focus is concerned, it's the same as clicking on the non-dialog window.) If there are no other open
windows, then the menu should not activate. (If this is not true in your case, then I'm not sure what's going on.)
A problem that arises is that if there are no other windows open and you hide the dialog window, what do you expect Paradox to do? In this
case, Paradox activates the menu again, because not doing so would cause you to be stuck (no menu, no form). In this case, the menuActions go
directly to the Paradox desktop, and are not seen by the form.
FROM: ADRIAN FOWLE
If you have a hidden form with desktopform property and its own menu, it gets focus and shows its menu if all other forms are closed. It is
very nice < g > but there are three problems :
- If a dialog box is open, such as a custom toolbar or floating hint box, the box gets focus and the menu from the last MDI form
persists.
- If you minimize the last MDI form, its menu persists, unless the desktop form and MDI form both have the standard menu property ticked.
This is against the usual advice for a multi form app and the interaction seems quite complex. (Sometimes the desktop menu can be restored by left
clicking the form icon then cancelling)
- If the desktop form displays its own menu, then calls a dialog box (even a non-modal one), the menus on the desktop interact as normal, but
the menu actions are seen by neither the desktop nor the dialog box - they are lost! This is similar to the situation that Robert Young described.
This is, I think, a Windows convention, but it means that the user cant access the help menu etc.
These are not the behaviours I desired - (I won't call it a bug) and I haven't found a useful workaround.