Menu Builder

[J. Landman Gay]

On 1/11/12 6:51 PM, Pete wrote:

> In the first screen, I click the New button and on the next screen, give
> the menu a name and leave the give the menubar a name and uncheck the box
> "move objects down to accommodate menu bar"  (I want the menu to be in the
> OS X menu bar).
>
> As soon as I click OK, all the controls on the open stack move up, some of
> them to be underneath the window title bar.  Uhhh, I asked for them not to
> be moved down, not to be moved up!
>
> Last time I used the menu builder, I had major problems - every time I
> opened the stack, it's height increased by the height of the menu -
> incrementally.  Never did get to the bottom of that, ended up setting the
> stack height by script to work around it.
>
> Is there another way to create OS X menu bar menus without using the menu
> builder?

I find the Menu Builder to be the easiest way to build menus and I use 
it all the time. I don't find it buggy at all, I think of it as one of 
the most convenient features LiveCode offers. But you do need to 
understand how it works, or it will *appear* buggy. What you describe is 
exactly what is supposed to happen.

There's info on how LiveCode menus work here: 
<http://www.hyperactivesw.com/mctutorial/rraboutMenus.html>

What that mainly says is: to accomodate both Windows (where menus are on 
the card) and Mac (where menus are in the system menu bar,) LiveCode 
places your menu group at the top of the card and leaves it there on a 
Windows machine, or scrolls the card up and out of the way on a Mac. 
That places the top 26 pixels or so offscreen and out of sight on a Mac. 
It's a little like setting the scroll of the card to 26; the card top 
has moved up and out of the window bounds.

When adding a new menu, you want blank space at the top of the card to 
allow room for the menu group. If you didn't create your menus first, 
you may have other objects already in the way. If so, they need to move 
down to accomodate the new group. If that's the case, you do want to 
check the box that moves everything down. If you've left room for the 
group already, skip that checkbox. It's a one-time relocation and very 
convenient when you decide in the middle of a project that you need a 
menubar on a screen where there are already objects in the way. I used 
to use a custom script for that until the Menu Builder came along.

Whether or not you move your objects down, if the stack has the menu 
group assigned, the card will scroll upward on a Mac. All your objects 
will appear to move up when it does that. They haven't really moved; 
their locations are still the same. But now that the top of the card has 
moved out of view, the objects have moved along with it and appear to 
have changed positions. It's visual only.

Menu builder is convenient, not only because it can create menus 
quickly, but because it can enter all those tedious switch/case scripts 
automatically. All I have to do after that is go in and fill in the 
working parts. It also lays out menu items in the right order so that 
Preferences and Help manage to show up in the right places cross-platform.

You can toggle the scroll on and off on a Mac by toggling "preview as 
menu bar". This just sets the editmenus property of the stack to true, 
which unscrolls the card. (I often just type the command into the 
message box.) Unscrolling the card brings the menu group into view, 
showing it as it will look on Windows, and making it easy to select and 
edit button scripts or lay out other objects. When I'm done, I set the 
editmenus to false again and the menu bar scrolls back up out of the way 
and appears in the system menu.

Tip: if you add a menu group late in development and need to move 
objects down to accomodate it, some objects may get pushed off the 
bottom of the card. You'll need to increase the stack height to adjust 
for the new locations.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com