I’m on macOS 12.7.2 using Xojo 2019r1.1… (don’t know when or if default Xojo mac MenuItem behavior changed)
I am writing an app that needs to be x-platform Mac/Win
While I don’t recall if it has always been true in my testing today on the Mac a MenuItem with subitems can still be chosen when one uses straightforward Xojo code
Bur Not so on windows where you can’t chose the parent item but can accesses it’s children.
In this case the parent item may or may not bend to be selctable le depending on situation, but in either case the submenu items MAY (or may not) be selectable so one still needs to be able to go down the tree regardless…
Where the parent MenuItem 2 is not selectable but active (it’s children can be reached) and the MenuItem 2 in the submenu may or may not be enabled (choosable).
The default Mac behavior I see is that the parent Menuitem2 is choseable, and disabling it means you can’t get at the it’s subitems!!!
So the only way I can se to get the behavior I need (without useable being able to chose something tha would not have an effect) is if there is a declare that would make the parent item not selectable, but still allow opening it’s submenu as on Windows.
I seem to recall that there was such a declare at one time but I can’t seem to find it…
I was pretty sure that Xojo MenuItems did not behave that way at one time… Must have been the pre-coca days…
But I also seem to recall there was declare to switch that functionality on… (so obviously it could turn it off) but i could be wrong or it was also in pre Coca days…
Anyway if it has been an issue they have been aware of for so long , it is likely never to get fixed .
I don’t have the MBS plugin set so I will just work around it … if a user selects a parent item that should be disabled, they will get a beep and no action. Not ideal, not professional looking , but usable.
I’m looking at Apple’s HIG and I think this paragraph applies:
Show people when a menu item is unavailable. An unavailable menu item often appears dimmed and doesn’t respond to interactions. If all of a menu’s items are unavailable, ensure that the menu itself remains available so people can open it and learn about the commands it contains.
I think that means that the parent item should be enabled so that it can still show all of its children. If that’s the thing you’re having trouble with, set it to Enabled and turn off AutoEnable.
I suppose a more accurate statement is that a menu that is constructed with built in Xojo classes doesn’t function like a native macOS menu.
If you look at something like the edit menu that is added automatically by the OS, clicking the parent item of a submenu does not act like it’s triggering an event and close the menu.
I would expect Xojo menus to have native behavior on each platform.
That feels like a bug.
In some ways… but can you name any Mac apps where you can actually select as the hit item minutes that has a children (a submenu)?
I looked at the ones I have and none I checked behave that way.
And IIRC at some point in the past RB/Xojo mac menus did not behave they way they do now. That issue/beedback seems to say that the Xojo behavior changed with the transition to Cocoa.
Not only the Edit menu, but this behaviour is like this in other (non-Xojo) apps.
At one time, I remember the Apple HIG stated explicitly that a submenu shouldn’t be choosable. I don’t have time now to check whether that’s still the case, but I’d think it is.
Presumably this means that it shouldn’t be choosable if none of the children are choosable. Or, the other way around, it should be choosable if any of its children (and grand-children etc) are choosable. And that this rule applies recursively.
But making this so is, I would have thought, up to the programmer.
You should be able to navigate the menu but you shouldn’t be able to click it to invoke an action.
Example:
1.Switch to the macOS Finder.
2.Click the Apple menu and move down to Recent Items.
3.Try clicking the Recent Items menu. You should find that the clicks are ignored.
If you build the same menu in Xojo you can click the Recent Items item and dismiss the menu which is wrong.
Click on “File” (i.e., the header of the File menu)
The File menu drops down. Now release the mouse and move it down to the first entry (which is New ->)
The submenu for New appears. Now click on that first entry of the File menu (i.e., do not move the mouse to the right, into the submenu).
You will find that BBEdit opens you a plain empty new editing window, as if you had selected the first item in the submenu. I’ve not seen (or at any rate, noticed) this behaviour in any other app.
I hadn’t noticed that in BBEdit before. However, I would class that as special behaviour and should not be the normal behaviour of menus (based on 30+ years of using a Mac).
I just did a quick test (which is hampered by the fact that Xojo removed the ability to get the underlying Handle in DesktopMenuItem on macOS, grrrrrrr)
Anyway, the only thing I could think of to try was to set the target property to nil which would mean that the menu can’t send events. Unfortunately, doing so disables the menu:
I then tried setting the Enabled property to True, but it made no difference. If anyone wants the code:
I put this in the MouseDown event of a canvas:
Dim m As New MenuItem("")
m.AddMenu(New MenuItem("One"))
Dim m2 As New MenuItem("Two")
m.AddMenu(m2)
m2.AddMenu(New MenuItem("Three"))
m2.AddMenu(New MenuItem("Four"))
// @property(weak) id target;
Declare Function getTarget Lib "Foundation" Selector "target" (obj As ptr) As Ptr
Declare Sub setTarget Lib "Foundation" Selector "setTarget:" (obj As Integer, value As Ptr)
// @property(getter=isEnabled) BOOL enabled;
Declare Function isEnabled Lib "Foundation" Selector "isEnabled" (obj As ptr) As Boolean
Declare Sub setEnabled Lib "Foundation" Selector "setEnabled:" (obj As Integer, value As Boolean)
setTarget(m2.Handle(menuitem.HandleType.CocoaNSMenuItem), Nil)
setEnabled(m2.Handle(MenuItem.HandleType.CocoaNSMenuItem), True)
Dim s As menuitem = m.PopUp
Return True
