Another discussion topic for everyone... I'm bringing this up now because it has to do with event handling - there'll (hopefully) be another menu-related discussion later, but we should think a little about the event handling related things now. How should menu commands be handled in the CGA? I don't think that simply attaching a callback to the menu item is a good solution - consider the following: The "About", "Quit", "Open", etc. menu commands are handled by the application - they are the same regardless of which window or widget has the input focus. The "Close", "Save", etc. menu commands are handled by the front window[MacOS] / the window to which the menu bar is attached[other platforms]. The "Cut", "Copy", "Paste" etc. menu commands are handled by the widget that currently has the input focus. In many (OO) toolkits that I know, a "menu command" event is first passed to the widget that has the focus. If that widget doesn't handle it, the event is passed on to the widget that contains it, and so on, then to the window, and finally to the application object. I've also seen toolkits where this "responder chain" (as it's called in Cocoa) can be freely configured. Also, should enabling/disabling menu items be handled in a similar way, using a callback, or should menu items be explicitly enabled/disabled by IO actions like enableMenuItem and disableMenuItem? The first is probably much more practical... Cheers, Wolfgang
--- Wolfgang Thaller
Also, should enabling/disabling menu items be handled in a similar way, using a callback, or should menu items be explicitly enabled/disabled by IO actions like enableMenuItem and disableMenuItem? The first is probably much more practical... I prefer the first approach. For that aim the Win32 API provides WM_INITMENUPOPUP message. Under GTK the "focus-in-event" is a proper replacement for WM_INITMENUPOPUP. Is there a way to implement the UpdateMenu command under MacOS.
Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Wolfgang Thaller wrote:
Also, should enabling/disabling menu items be handled in a similar way, using a callback, or should menu items be explicitly enabled/disabled by IO actions like enableMenuItem and disableMenuItem? The first is probably much more practical...
Preferably the latter. If a toolkit supports "tear-off" menus, the
menu can remain on screen for an extended period, so the status of the
individual menu items can change while the menu is displayed.
Relying upon an on-popup callback is likely to result in tear-off
menus not working properly.
--
Glynn Clements
Also, should enabling/disabling menu items be handled in a similar way, using a callback, or should menu items be explicitly enabled/disabled by IO actions like enableMenuItem and disableMenuItem?
Preferably the latter. If a toolkit supports "tear-off" menus, the menu can remain on screen for an extended period, so the status of the individual menu items can change while the menu is displayed.
Relying upon an on-popup callback is likely to result in tear-off menus not working properly.
Well said. I also vote for the latter. Why? it is simpler, it can be implemented anywhere, it is well understood, it is needed anyway to support tear-off menus, and finally, a toolkit can optionally emit "initmenu" events for application writers that want to optimize their calls to enable/disableMenuItem. -- Daan.
Strictly speaking the "initmenu" approach doesn't exclude the second approach but only if the "initmenu" menu event exists for all target platforms. Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Krasimir Angelov wrote:
Strictly speaking the "initmenu" approach doesn't exclude the second approach but only if the "initmenu" menu event exists for all target platforms.
Sure; even with an on-popup callback, the bodies of such callbacks
typically consist of actions which set the states of the menu items.
Such actions could just as easily be used elsewhere.
The problem with the on-popup approach isn't that it's hard to
implement, but that it only works if menus are guaranteed to be
sufficiently short-lived that the state of the items won't change
while the menu is open (e.g. if the menu is guaranteed to disappear as
soon as an item is activated).
IMHO, providing an on-popup callback is positively inviting
programmers to write code which only works correctly on platforms
which don't support tear-off menus.
--
Glynn Clements
--- Glynn Clements
IMHO, providing an on-popup callback is positively inviting programmers to write code which only works correctly on platforms which don't support tear-off menus.
I think this touches on a general issue which we should consider. I think that CGA implementors should have a standard way to introduce extentions to the standard. Perhaps some kind of naming convention so it would be extremely easy to recognize these extentions. Similar to the C++ standard which allows compiler macros that begin with an underscore and then a capital letter. David J. Sankel
participants (5)
-
Daan Leijen -
David Sankel -
Glynn Clements -
Krasimir Angelov -
Wolfgang Thaller