Page 3 of 3
Re: Menu Builder Woes?
Posted: Wed Mar 05, 2014 2:26 am
by FourthWorld
thatkeith wrote: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.

Re: Menu Builder Woes?
Posted: Wed Mar 05, 2014 5:29 pm
by 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.
Re: Menu Builder Woes?
Posted: Wed Mar 05, 2014 6:12 pm
by 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
Re: Menu Builder Woes?
Posted: Thu Mar 06, 2014 9:39 am
by keram
Hi Jacque,
jacque wrote: 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
Re: Menu Builder Woes?
Posted: Thu Mar 06, 2014 1:50 pm
by 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?)

Re: Menu Builder Woes?
Posted: Thu Mar 06, 2014 5:41 pm
by 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".)
Re: Menu Builder Woes?
Posted: Mon Mar 10, 2014 9:12 pm
by 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
Re: Menu Builder Woes?
Posted: Wed Mar 12, 2014 11:41 am
by 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