(Cocoa) Orphaned menus left in auto closed windows

I have a timer that auto closes a window with a custom menu. If any menu is displayed, the auto closing widow removes the menu but leaves the orphaned menuitems showing.

I understand that timers fire when menus are selected in cocoa. Anyone know of an easy way to dismiss the orphaned menu list displayed when a window auto closes?

Thanks,

Keith DeLong

[quote=165226:@Keith DeLong]I have a timer that auto closes a window with a custom menu. If any menu is displayed, the auto closing widow removes the menu but leaves the orphaned menuitems showing.

I understand that timers fire when menus are selected in cocoa. Anyone know of an easy way to dismiss the orphaned menu list displayed when a window auto closes?
[/quote]

Showing a new window, even dismissing it right way, will change the current menu.

Thanks for the reply Michel.
Unfortunately, while the menubar does change, any menu list that is showing is orphaned.

I’ve put a sample project here:
Auto Close menu bug demo

Tried it with 2012 R2.1 Cocoa. After the menu item is removed the open menu shows only for a second here and then closes.

The bug does not appear in Xojo 2014R3.2 with your demo project. I tried opening it in 2011R4.3 and the issue does not manifest either. It does show up in 2012R1.2 and obviously your 2013.033.

You may want to use a previous version, or upgrade to Xojo.

You should file a bug report if you can reproduce it in 2014r3. As a workaround for now, you can clean up after the menu with this bit of code:

[code] Declare Function NSClassFromString Lib “Foundation” (className As CFStringRef) As Ptr
Declare Function sharedApplication Lib “AppKit” Selector “sharedApplication” (obj As Ptr) As Ptr
Declare Function mainMenu Lib “AppKit” Selector “mainMenu” (obj As Ptr) As Ptr
Declare Sub cancelTrackingWithoutAnimation Lib “AppKit” Selector “cancelTrackingWithoutAnimation” (obj As Ptr)

Dim NSApplication As Ptr = NSClassFromString(“NSApplication”)
Dim NSApp As Ptr = sharedApplication(NSApplication)
cancelTrackingWithoutAnimation(mainMenu(NSApp))[/code]

It violates the OS X User Interface Guidelines - never remove menu from the menubar.

Have to correct myself. The menu disappears on moving the mouse or a key press.

Change menu bar then?

We don’t do that either on Mac.
Technically the main menubar should be left untouched, and items should be enabled/disabled as needed in the submenus.

Thank you for the work around with the declare Joe. It’s just what I needed as I am stuck using Xojo 2013R3.3.

This bug appears to be resolved in the latest Xojo release.

[quote=165317:@Tim Parnell]We don’t do that either on Mac.
Technically the main menubar should be left untouched, and items should be enabled/disabled as needed in the submenus.[/quote]

What is mandatory is the Human Interface Guidelines. Fortunately not programming techniques. Otherwise we all would have to use XCode and not Xojo. In fact what counts is to present the user with a menu, with at a minimum File and Edit. As how menus change within the code under the hood, the sky is not going to fall because you switch menu bars, which is a perfectly acceptable way of managing menus in Xojo.

[quote=165317:@Tim Parnell]We don’t do that either on Mac.
Technically the main menubar should be left untouched, and items should be enabled/disabled as needed in the submenus.[/quote]
Confused now (especially by Joe liking your answer).

MenuBar is window specific. So why can we set a different menu bar for window2 if it isn’t allowed???

I would argue that window2 SHOULD have its own menu bar as it has a menu specific to it.

About Menus

[quote=165413:@Markus Winter]Confused now (especially by Joe liking your answer).

MenuBar is window specific. So why can we set a different menu bar for window2 if it isn’t allowed???

I would argue that window2 SHOULD have its own menu bar as it has a menu specific to it.[/quote]

Just because you can doesn’t necessarily mean you should.

I’d still content that in his case he should.

I do not see anything at https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/MenuAppearanceBehavior.html#//apple_ref/doc/uid/20000957-CH23-SW1 saying the only way menuitems shoud be managed is by removing and adding them.

From what I understand of that page, menus should be consistent with guidelines, and behave a certain way, which is possible to obtain by adding/removing/enabling/disabling menuitems, or switching menubars where such items have been already added/removed/disabled or enabled.

[quote=165425:@Joe Ranieri]@Markus Winter I would argue that window2 SHOULD have its own menu bar as it has a menu specific to it.
Just because you can doesn’t necessarily mean you should.[/quote]

O wise one, do enlighten us about the mysteries of your sentence. Why is it technically bad to affect different menubars to different windows ? Some bugs we are not aware of, do you have plans to remove that feature, or something else ?

In general, the contents of the menubar on OS X don’t change when you switch windows in an application. The HIG doesn’t come out and say this, but I’d say it’s a platform expectation.

No technical issue, so. You reassured me.

I understand it has become common culture to expect the menubar not to change, but items to be enabled/disabled, or added/removed as needed. Removing a menu item from the menu bar was not so much what I proposed, apart from trying to solve that pesky dropped down remnant menu you so elegantly killed with a declare.
My point was that using the menu editor to modify menuitems is a whole lot easier and possibly less fragile than cramming code in methods to do all that editing. I always prefer editing things in a graphic representation than in code, and that is one of the strong points of Xojo I appreciate.

True. But that is not the case here. Keith changes the contents of the menu bar when he switches windows.

I would hazard that changing menu bars then is more in line with the HIG than an additional menu (that is easily overlooked) popping in and out of existence.

Alternatively he should have the menuItem there all the time.