I made a keyboard shortcut in the Main Menu under File, to close a window.
I added a menu handler to 2 windows
see screenshot
only the ABOUT window works
the video window DOES NOT work.
cmd + . will close the the video window, I have no idea why that works, I didn’t tell it to.
can anyone see what I am doing wrong?
thanks for the file.
I did everything you did.
the about window DOES close
the video window DOES NOT close
[quote=222571:@Shawn Brady]thanks for the file.
I did everything you did.
the about window DOES close
the video window DOES NOT close
[/quote]
Could you post your project ?
Does ‘Close’ work with the mouse in Windows Menu ?
You’ve used cmd + W twice in Windows Menu, that will only work for the first Menu (close about)
Remove both cmd + W from Windows Menu, use cmd + W on File Menu Close
axel, I removed both cmd + w
the close button work on both windows
where is File Menu Close
you must add a new menuitem in File Menu, look at the example that I posted
When there are identical menu handlers on both app and windows, only the menu handlers in App fire.
If you want to use Cmd-W you must remove the App menu handlers and use only the ones in windows.
I have found the opposite to be the case: the window menuhandler overrides the one in app. The hierarchy is supposed to be Control → Window → App.
(Of course, that’s on Windows. Perhaps OS X behaves differently?)
[quote=222873:@Tim Hare]I have found the opposite to be the case: the window menuhandler overrides the one in app. The hierarchy is supposed to be Control -> Window -> App.
(Of course, that’s on Windows. Perhaps OS X behaves differently?)[/quote]
At any rate, seems to me using the same menu handler all over is a recipe for confusion.
I would dedicate a MenuBar per window, so that would enable me to precisely tune the keyboard shortcut and menu handler. For instance AboutMenuBar would replace self.Menu in About.Activate, and MainMenuBar would resume in About.Deactivate.
AboutMenuBar would use a different name for the menu option that closes the About window. It would make more sense to have an item such as “Close this window Cmd-W” called WindowCloseSelf with the same menu handler on the window containing self.close.
On the Video window the same kind of technique would have WindowCloseSelf refer to the window item instead.
The alternative is to dynamically modify the content of the Window menu dynamically, but it is somewhat more involved.
Menus and the menu handler system in Xojo are exactly designed to be able to use one and only one menubar for an entire application (which on OS X is by the way recommended if not more or less mandatory).
You implement a menu handler at the level you want. If you don’t implement a menu handler at a certain level, the framework will travel up in this order (as Tim has mentioned):
This is IMHO an unfounded preconception. Otherwise the menuBar property of a window would not exist.
http://documentation.xojo.com/index.php/Window.MenuBar
I have used several menubars in my applications for over a decade. While keeping with the HIGs on OSX, mind you. Simply using several menubars avoids a lot of clockwork shuffling menuitems in code. It is a different programming style you may not like or understand, but it is as valid as using several Container Controls.
As I understand it it exists mainly because of the Windows OS, where each window has its own menubar.
To quote the LR you should have read :
[quote]OS X
On OS X, if no MenuBar is assigned to the window, Application.MenuBar is used. To hide the MenuBar, set the MenuBar property to None (in the Inspector) or Nil (in code) for both the window and the Application.[/quote]
This clearly means that property is to be used in OS X, and simply App.Menu is used if not set.
Let me explain a typical use of two menubars instead of a lot of code nitty gritty in an OS X application.
On one window, I have the need for a special handling for EditCopy.
I duplicate MainMenu without changing anything to its presentation, therefore keeping perfect compliance to HIG. But in MainMenuBar1 I just change the Copy menuItem from EditCopy to myEditCopy.
In that window where I need special handling, I set Window.Menu to MainMenuBar1, and use a menu myEditCopy menu handler. When not using that window, the app reverts naturally to EditCopy. No additional coding.
This has absolutely nothing to do with the particular way Windows presents menus. It has everything to do with avoiding unnecessary code.
Once again, it is not mandatory or forbidden. It is just an available programming option. Each one his own style.
Just implement the menu handler for EditCopy in this specific window. Do not implement it in the other window and the Xojo framework will handle the copy there. Done. No need to copy the entire menu bar and change the name of the menu item from EditCopy to myEditCopy.
I didn’t say anything the like.
You are right. It does work.
Nevertheless, editing menus in the menu editor and switching menu bars is often a good way to avoid extra coding to change the menu items.