Has the desktop menu option autoenable's behaviour changed

General
1

I’m on macOS and bringing an old application up to date and converting it to API2.
I updated to Xojo2024R1.1.
The behaviour of menu option AutoEnable seems to have changed. My understanding was that it would automatically enable if there was a handler for it on the current window / object otherwise it would disable. Once enabled you could disable it again in the MeuBarSelected event.
What I’m finding is that menu items always have to be explicitly enabled / disabled, for example I have a File Page Setup option in the new version of this program and currently no handler for it anywhere, yet is is enabling. AutoEnable is set. File Save is also enabling on my frontmost window which has no edit functions and hence nothing to save. There is nothing is that window which can enable save.

What am I doing wrong?

2

Same here. I had to spend a man day of effort to add code to a plethora of MenuBarSelected events to do the enabling programmatically.

3

Honestly it sounds like you’re doing everything right and something got broken in the framework. Can you make an example project just to be sure?

4

I’ve been messing around with my code and found turning off AutoEnable seems to improve things a bit, especially if you have a window that doesn’t need a particular menu.

5

Ok … here’s an app. There’s absolutely nothing in it … default. All I’ve done is added a File Page Setup and File Print … and they’ve both enabled.

/Users/Jack/Documents/REALbasic/LearningCurve/testMenu.xojo_binary_project

6

You need to use dropbox, one drive, google drive or other sharing system and paste the link here.

7

Sorry about that … seems to changed the way this works as well.

8

I think it’s a known issue: https://tracker.xojo.com/xojoinc/xojo/-/issues/75955

1 Like
9

Ok, fair enough.
There are bugs and there are bugs. This one is quite nasty in that it seriously affects peoples code and could involve a great deal of reworking. Any idea when it is likely to get fixed?

10

Expected to be part of Xojo2024r2 according to the comments there:
image

11

I don’t think it is just swapping windows either. If you close all windows and don’t have a handler in the App object it should be automatically disabled and it isn’t.

12

Good point.
The report made was certainly based on the user’s specific issue.

13

Well it seems like you both have pre-release access and could let the rest of us know whether this has truly been fixed or not (if they’ve posted something… I don’t even know that much). The ticket is marked as fixed though.

14

No beta version available yet. The latest status is Reproducible.

15

Okay, I guess we’ll just have to wait and see.

Um… it says REMOVED the Reproducible label.

Screen Shot 2024-05-16 at 11.16.50
Screen Shot 2024-05-16 at 11.16.50826×62 7.85 KB

Screen Shot 2024-05-16 at 11.16.57
Screen Shot 2024-05-16 at 11.16.571204×62 11.4 KB

16

So it does. Teach me to read on a phone.

17

Can anyone confirm this issue has definitely been sorted.
As far as I can tell if you explicitly disable a menu item it will remain disabled until you explicitly turn it on again. I understood for each invocation it is enabled unless you turn if off in the MenuBarSelected event.