Menu Builder Woes?

[FourthWorld]

Thanks for your patience!

No problem. When I first started using LC I used to curse like a sailor every time I found something that wasn't like SuperCard. It took me some time with other platforms to slowly appreciate the "why" of the things that used to annoy me. So I went from cursing sailor to fanboy, but it certainly wasn't all in one day.

[jacque]

I'm coming in late here, but when I first started using MetaCard the author said to me that I should always begin with a menubar at the top of the stack. The menubar is part of the card, and layout goes underneath that space. Even if I don't know what I'll be putting in the menubar, I always place a skeletal one in there right from the start. The rest of the card objects go underneath, exactly as Windows and Linux users will see it. After that, everything just works. On Mac, the menu slides out of view, on Windows/Linux it looks the way I set it up. No card dimensions change, and card locations are always consistent.

If you do it that way, you won't even have to think about it.

[thatkeith]

All significantly valuable info. I wish I'd had this conversation a long time ago!

One of the things needed, I feel, is a "So you want to..." set of focused instructions on things such as making menus, and many others. If something like that was available and had one or two dozen topics it could probably make a significant positive impact. If it was easy to find of course...

Keith

[keram]

Hi Jacque,

when I first started using MetaCard the author said to me that I should always begin with a menubar at the top of the stack. The menubar is part of the card, and layout goes underneath that space. Even if I don't know what I'll be putting in the menubar, I always place a skeletal one in there right from the start. The rest of the card objects go underneath, exactly as Windows and Linux users will see it. After that, everything just works. On Mac, the menu slides out of view, on Windows/Linux it looks the way I set it up. No card dimensions change, and card locations are always consistent.

It's good to know this. But what to do when I already have a stack designed for both mobiles and Windows and Mac but without any menus yet. Is it best to create a new stack, put the menus on it and then copy all the cards from the existing stack to the new one with the menus?
Or is there any other, better solution?

keram

[thatkeith]

Hard to say without knowing more about their construction, but if you don't have any objects positioned vertically using scripts then you *could* simply add 22px to the stack's height, move the existing contents down by 22px, and add your menu button group in the newly-exposed top part. In Windows & Linux the result would be a window with menus at the top as per normal, and in the Mac the card would slide up (when the menubar propserty is set to the menu group name) by 22px, returning the arrangement of objects to the original top-of-card presentation.

If you do have objects positioned vertically in any way by scripts, those scripts would need to be given an additional 22px to the top references. It shouldn't be complex but you should think it through and test this behaviour specifically.

(Izzat right, folks?)

[jacque]

Izzright. I have a little handler I run when I need to add a menubar later on during the layout process.

Code: Select all

on pushDown tH,tY
  if tH = "" and tY = "" then
    ask "Enter horizontal and vertical offsets:" with "0,38"
    if it = "" then exit pushDown
    put item 1 of it into tH
    put item 2 of it into tY
  end if
  if tH = "" then put 0 into tH
  if tY = "" then put 0 into tY
  set cursor to watch
  repeat with x = 1 to the number of bgs
    set the left of bg x to the left of bg x + value(tH)
    set the top of bg x to the top of bg x + value(tY)
  end repeat
  repeat with x = 1 to the number of cds
    go cd x
    repeat with n = 1 to the number of cd parts
      set the left of cd part n to the left of cd part n + value(tH)
      set the top of cd part n to the top of cd part n + value(tY)
    end repeat
  end repeat
end pushDown

I use this for menus, but also to move things horizontally during development. For menubars, you only need the vertical part. Call it like this:

pushdown 0,22

That will move everything in your stack down 22 pixels. (The reason it uses "parts" instead of "controls" is because it was written for my HyperCard conversion tutorial, where "parts" is the HC terminology. You could use "controls", it's synonymous. I also can't recall why I used "value" except that at one point there was an error generated and that fixed it. The handler is ancient, it probably works now without "value".)

[TerryL]

I was able to make the default File-Edit-Help pull-down menu in a clean stack using Menu Builder on Win7 without issue. Thanks LiveCode! (Tools > Menu Builder, click "New", click "Auto Script" for each hilited menu).

I was disappointed the auto scripts didn't contain any actual menuItem code, just the framework. So each person must struggle with creating standardized menuItem routines on their own?

I searched the Forum and LC Lessons but couldn't find any examples. I did find some examples on Jacque's website, http://www.hyperactivesw.com/mctutorial ... Menus.html. Thanks Jacque.

Could someone share a few of their File-Edit-Help code snippets?

In the spirit of sharing, I modified Jacque's code slightly to be more specific to the task of moving all controls in a stack down 22 pixels to make room for a new pull-down menu. Put the code in a button and temporarily paste on the first card of a COPY of a stack. Delete button when done. Thanks again Jacque.

Edit1: Background groups, substacks, and data grid sub-controls required screening to work as intended. Updated to v1.1
Edit2: Menu Builder has an undocumented feature to move existing stack controls down too. Tools > Menu Builder > New. At the bottom of the dialog is a checkbox to "Move objects down to accommodate a menu bar." It also increases the stack height appropriately. Tested and works with data grids.

Code: Select all

on mouseUp  --v1.1, make room for a pull-down menu
   local tVert = "22", tResize
   answer "Move controls down 22 pixels to make room for a pull-down menu?" with "OK" or "Cancel" titled "Move Controls Down"
   if it = "Cancel" then exit to top
   set the cursor to watch
   lock screen for visual effect
   repeat with i = 1 to number(grps in this stack)  --background group controls
      if the backgroundBehavior of grp i of this stack = "false" then next repeat
      set the top of grp i of this stack to (the top of grp i of this stack + tVert)
   end repeat
   repeat with i = 1 to number(cds in this stack)  --cards
      repeat with j = 1 to number(controls of cd i of this stack)  --card controls
         if the short name of control j of cd i of this stack begins with "dg" then next repeat  --data grid parts
         if the short name of control j of cd i of this stack begins with "group id" and the backgroundBehavior of control j of cd i of this stack = "true" then next repeat  --bg grp controls
         if the long name of control j of cd i of this stack contains "of group" then next repeat  --subcontrols
         set the top of control j of cd i of this stack to (the top of control j of cd i of this stack + tVert)
      end repeat
   end repeat
   put the resizable of this stack into tResize  --store
   set the resizable of this stack to "true"
   set the height of this stack to (the height of this stack + tVert)  --resize stack
   set the minHeight of this stack to (the minHeight of this stack + tVert)
   set the resizable of this stack to tResize  --reset
   unlock screen with visual effect dissolve
end mouseUp

[keram]

Thanks Terry and Jacque for your handlers for moving the menu.
They do move the objects properly except the data grids and other group objects - in these cases they move them 3x the distance respective 2x the distance.

keram