Is there a different way in Xojo to make a MenuItem invisible? (Or deleted for that matter.)
In RealStudio I created a MenuBar like this:
Help
[other menus]
About App (MenuItem)
About App (AppleMenuItem)
[separator] (AppleMenuItem)
Preferences 1… [PrefsMenuItem)
Preferences 2… [PrefsMenuItem)
On Mac this would give me this type of behavior in the Apple menu, since they are AppleMenuItems and PrefMenuItems.
About App
Preferences 1…
Preferences 2…
Of course this would look ugly on Windows, in the owner Window Open event, I did this:
#if TargetWindows Then
mnuAboutApple.Visible = false
mnuAboutAppleSep.Visible = false
mnuPrefs1.Visible = false
mnuPrefs2.Visible = false
#endif
This works under RS2011r3, but the menus are still visible in Xojo 2019r1.1 on Windows. (I have a test app if you want to see it)
Any idea why?
Hi Garth,
If you look at the MenuItem.Visible documentation, it says “This property does nothing on Windows so use MenuItem.Remove instead.”
As well, just so you know AppleMenuItem is deprecated (prior to API 2.0) and it is recommended to use ApplicationMenuItem
I hope that helps.
Thanks for suggesting this - although (otherwise I would have figgered it out) this area is pretty confusing, for a bunch of reasons.
-
Strangely, the LR for RS2011r3 says MenuItem.Visible does not work for Windows - but it does!
-
So, if it is possible on Windows, why not leave it there and not think Remove would be the Windows-way? And isn’t that very anti-Xojo, shouldn’t the goal being the platforms are consistent?
-
At first I thought WHAT? It’s Remove(index) but these MenuItems are not part of an array. I went into the Xojo LR and it says “for 2019r2 use RemoveMenuAt” Well, I’m not using r2 yet, good… but… MenuItem.Remove() is overloaded as (index) and (Child). (Index) would not work for me, but (Child) would, and it does and works for me thank you.
BUT - when I go to r2, my code will break because Remove will be gone and I can’t remove the MenuItem on Windows because (Child) went with it. So I won’t even be able to do what I want to do, which is a common thing.
Who at Xojo is designing this stuff???
[quote=463448:@Garth Hjelte]3) At first I thought WHAT? It’s Remove(index) but these MenuItems are not part of an array. I went into the Xojo LR and it says “for 2019r2 use RemoveMenuAt” Well, I’m not using r2 yet, good… but… MenuItem.Remove() is overloaded as (index) and (Child). (Index) would not work for me, but (Child) would, and it does and works for me thank you.
BUT - when I go to r2, my code will break because Remove will be gone and I can’t remove the MenuItem on Windows because (Child) went with it.[/quote]
On the documentation page for MenuItem.Remove there are two overloaded methods. Only the first one is deprecated for API 2 and MenuItem.Remove(Child as MenuItem) is staying as is (not changed in API 2).
I was confused about this at first too. See <https://xojo.com/issue/58133> and read the last note.
[quote=463448:@Garth Hjelte] It’s Remove(index) but these MenuItems are not part of an array. I went into the Xojo LR and it says “for 2019r2 use RemoveMenuAt” Well, I’m not using r2 yet, good… but… MenuItem.Remove() is overloaded as (index) and (Child). (Index) would not work for me, but (Child) would, and it does and works for me thank you.
[/quote]
Remove(index) has nothing to do with them being arrays or not
a Menu (say the file menu) has children and those children have “names” and they have “positions” - the first, the second the third etc.
And you can remove “the first one” or second one etc regardless of its name by using the index (or “position”)
I usually use
themenu.enabled = false
themenu.visible = false
themenu.text = "-"
On windows, what you end up with is a disabled separator.
It might as well be, it’s programmatic hell otherwise. It you are adding and deleting up the stream the indexes change. (Are these indexes just unique ID’s? They aren’t ordered or anything?)
I guess it’s time for a VCRIHTW (Very Common Routine I Have To Write) which finds a MenuItem in a “column” based on it’s name and returns it’s current index. Although it can’t be foolproof (?) because menus can have the same name. Maybe this is a new need to use Introspection?
I found the MenuItem.Tag property to be helpful, to uniquely identify menus that require special handling.
Good luck.
But also… [having a knife at your throat] <> [being dead] - but it’s awfully close to it!!! =)
I think my complaint here is that I would have thought that REAL/Xojo would have had a perfectly consistent MenuItem schema by now. No serious complaints, though, it’s pretty dang good. I just found something that is frankly a bit weird.
But back to deprecation (digression)… see here Deprecations — Xojo documentation
I would think there should be a fourth category; perhaps called Obsolete. Take RBVersion for example. XojoVersion works exactly like that, it was only renamed for political reasons (change of company name). So it’s like a deprecated item that will NEVER be removed. I want to use RBVersion for a long time, because I want to continue to use the same source code in RS2011r3 as I do new Xojo versions. Since RBVersion is used in #if statements, I can’t wrap it in a function.
[quote=463488:@Garth Hjelte]It might as well be, it’s programmatic hell otherwise. It you are adding and deleting up the stream the indexes change. (Are these indexes just unique ID’s? They aren’t ordered or anything?)
[/quote]
positional indexes just like items in an array
if you remove index 0 then what was at index 1 becomes index 0 etc
I dont tend to use indexes very often
Finding them by name is much simpler and then they can be in any position or order
introspection is NOT required here
Everything you need is exposed already
It could be removed - its actually not hard to
BUT one thing for sure is that it cannot be removed quietly
The compiler would complain that its missing if it were removed and you had used it
And then you could deal with it at that time