On Oct 4, 2006, at 1:54 PM, Arnaud Nicolet wrote:
Le 4 oct. 06 à 22:34 Soir, Víctor Fernández Fernández a écrit:
is not the same ? the window is inside the application.
It's not the same.
For example, you can have an application with no window open (e.g
the user closed the last document window).
In that case, if you set the menu handler in the window, nothing
happen (since the window is not there). If you set the menu handler
in the app class, this app class can handle the menu item
regardless of the fact that there is a window or not (if no open
window handles the menu item first).
Expanding on this, you can have menu handlers for menuitems all over
the place; even duplicates of the same code. What is critical is:
a) The order of events of menuhandlers.
b) The enabling of these menuhandlers.
Jon Johnson recently wrote in a reply:
---------------------
"On Jul 26, 2006, at 4:47 PM, Jonathan Johnson wrote [in a reply to
recent changes].
The new order is (as documented in the release notes somewhere):
1) Focused Control Menu Handler
2) Intrinsic focused-control menu handler (ie, built-in handler)
3) Window Menu Handler
4) "Parent" window menu handler (in the case of floating windows,
this would be the next non-floating window)
5) App Menu handler
6) MenuItem Action event"
---------------------
That takes care of the order. What's left is the enabling of the
handler.
When you start adding menuitems to a Menubar, the default setting is
AutoEnable=True. This makes it easier than when I started in
REALbasic as that wasn't available until Rb 5.0. All menuitems had to
be enabled manually.
Where you actually put the handler(s) for that menuitem is largely
dependent on when you want it available. As others stated, if the
handler is in a window, it is useless when the window is not open. It
may be auto enabled and appear active but it won't have any code to
execute.
Still, a menuitem is also only valuable when it is enabled at the
correct moment. This is where you can get into trouble by having a
handler in the App, with Auto Enable true, and nothing for it to act
on or code that is written for a window that isn't currently
frontmost but expected to be.
A rule of thumb is, if the Menuitem needs to operate at all times,
then make its AutoEnable property true and put it in the App
subclass. If it needs to be enabled differently then enable or
disable it in code in the EnableMenuItems event where it is relevant.
If the Menuitem only pertains to a Window when it is open, then put
the handler there.
Remember that even an AutoEnabled menuitem can be disabled or made
false in the EnableMenuItems event when the event is higher in the
order mentioned above. For example, you could have an Auto Enabled
"File>New" Menuitem, with it's handler in the App object, but disable
it in a window by having FileNew.Enabled=False in its EnableMenuItems
event. If the Window is closed, however, it would then be enabled
again as the window is not there to block it.
Terry
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
