LiveCode Forums.

The menu builder on OS X is just so buggy it's impossible to add menus reliably to my app. Is it possible for me to create a menu in script instead?

Anyone know if the menu builder is fixed in 3.5?

Jeff M.

Sorry for the outburst. I've been trying to get this to work properly for the past 2 hours, trying every iteration of steps I can imagine.

Regardless of what I do, either controls are in the wrong position while editing the app, or they are wrong when the standalone starts up (that's what I meant by "buggy" and "impossible to use").

I sure hope that this bug is resolved in 3.5.

Jeff M.

Hi Jeff,

Sorry to hear you're feeling frustrated. You didn't describe exactly what you mean by controls being in the "wrong position". But if you're on OS X you may be running into a bit of quirky behavior that has to do with the fact that menus on OS X are at the top of the screen, while Windows menubars are in the application window. To compensate for this Rev "helpfully" decreases the window size by the height of the menubar when you set the menu group to be a main menu in OS X.
Have you looked at section 7.13 of the Revolution User Guide: Programming Menus & Menu Bars? (This can be found in Revolution Documentation > User Guide.) It explains this behavior and may offer some guidance.
In addition, on my Revolution tutorials site I have a lesson on creating menus from scratch (i.e., without using the Menu Builder.) You may find that useful. See http://revolution.byu.edu/menus/menus.html.
Finally, have a look at the Revolution Scripting conferences from a few years back. http://support.runrev.com/scriptingconferences/ Number 9 was on Menus and should contain some good pointers on using the menu builder.

Hope this helps.

Devin

Devin,

Thank you so much for your reply. Yes, the frustrations on OS X revolve around Revolution being "nice" and moving the controls around. No matter what I seem to do, either the controls are misplaced in the IDE while editing, or wrong in the standalone later on.

I'll take a look at the User's guide again. I remember going through it, but not seeing much. At the time, I wasn't dealing with these problems (it was before I was ready to add my menu). Perhaps it's worth another read.

And I very much appreciate your notes on creating menus from scratch without the menu builder. That may be exactly what I end up doing. I'll give that a try when I get home tonight.

Thank you again! I'll post a follow-up with my results.

Jeff M.

Jeff,

I and others get around this "helpfulness" on OS X by NOT checking the "Set as Menu Bar in OS X" check box in the menu builder. This is what I do to avoid the resizing issue (from memory, so tell me if it doesn't work for you.)

Leave enough blank space at the top of your window to show a menu bar when in Windows.
Create the menu in the menu builder but don't check the "Set as Menu Bar..." checkbox.
Exit menu builder.
Hide the menu group.
Do on preOpenStack:
if the platform is "MacOS" then
hide group "mymenu"
else
show group "mymenu"
end if
Once it's hidden, go ahead and do in the menu box:
set the menubar of this stack to "mymenu"
It should then show up in the Mac menu bar when in browse mode.

I think the trick here is to have the menu group hidden when you set the menubar property. Like I said, I'm going by memory, so I may have missed a detail, but this has worked well for me.

Devin

Devin,

Thanks for all the suggestions. Here's what I finally ended up doing, and hopefully putting it here for posterity will help others. Still, I hope that the Rev team can make a menu builder that "just works" for 3.5 and beyond...

1. As you suggested, I left enough space at the top of the stack for the menu. Used the Menu Builder, but elected to NOT let Revolution shift my controls down, and elected to NOT "set as menu bar on Mac OS".

2. Took my controls near the top (which act as my "toolbar") and grouped them together, and called them "Toolbar".

3. Made the other controls on the card that needed to, bind to the group "Toolbar" in the geometry manager, so they could resize/move accordingly.

4. Overrode the savingStandalone message to something like this: While in the IDE, I use the menu in the stack window, but the final, saved application just does the right thing. However, this is *almost* what I want. I say "almost" because, of course, the platform always returns the platform I'm developing on. I'd need to rebuild the application on Win32 to get the menu bar to stay put on Win32.

Ideally, savingStandalone would be called multiple times with a parameter indicating what the target platform was. But that's a feature request at this point. But perhaps someone knows how I can get the behavior I want?

Thank you so much for the advice and help. I'm glad I was able to get this working finally!

Jeff M.