Studio resizeing stack behind back of user...

[J. Landman Gay]

Stephen Barncard wrote:

> With Xtalks, I divide up the functionality first, make the parts work 
> individually, then bring them together in the middle, and spend the rest 
> of the time making it all work together, and that's the point where I 
> make it pretty and add menus.

I think most of us work that way; I know I do. Rev just lends itself to 
that kind of tinkering and its natural to take advantage of it.

> 
> In my project, if I had done the menus first, I'd be changing them all 
> the time.

Right, but note that you don't have to build the menu ahead of time, 
just put a placeholder there to reserve the screen space. What I usually 
do is just open the menu editor, click "okay" and put up the default 
menubar. I don't bother scripting it, or adding things to it, or 
anything. Just stick one up there right at first. I usually don't know 
what menus I will need, but 99% of the time I do know whether the app 
will eventually have a menu bar. That's all that is necessary at first. 
It is very easy to edit it later when you're ready.

> And while I'm in the IDE, I want the IDE features. Also how does one 
> deal with one's own menus 'getting in the way' when testing and trying 
> to use the IDE menus? Just seems like a hassle.

It isn't hard. There are a couple of ways to manage this. One way is to 
just leave editMenus set to true. That gives you the best of both worlds 
on a Mac. You have Rev's native menus at the top as usual, and the 
stack's menu bar inside the stack window (ala Windows). The stack menu 
responds to the mouse, so you can use that if you want to test your own 
menus. And the Rev menu responds to both mouse and keyboard shortcuts, 
so you still have full use of that one.

Another way is to go ahead and place your stack menu as the Mac menu 
bar. If you do that, then whenever your stack has focus, its menus will 
be used. If you click on any Rev window or palette, the Rev menus come 
back. You can alternate which menu you see simply by clicking on a stack.

I use both methods. It is easier for me to keep the menus showing in the 
stack window during development, and when I am testing, I put them up 
top in the normal Mac position.

> 
> I develop routines with buttons with or single commands. When I started, 
> I had no idea what was going to be in those menus. In a long 
> development, features change.

To edit an existing menu, just choose the menu editor and make your 
changes. It's very easy. I do it all the time.

> 
> I'm planning to put my future menus in their own stack, and "set the 
> menubar to..."
> 
>  I've heard it works, does anyone have a downside for this approach?

As Tereza mentioned, it will fail if you build for Windows. If you are 
deploying for Mac only, then it should work okay provided your menus 
don't make calls to card scripts. I routinely put 1-line calls into my 
menu handlers and then store the full handler in the stack somewhere 
(this makes them easy to test from the message box and easy to get to 
for editing.) A menubar that lives in a separate stack won't see 
handlers stored in the cards of the main stack. You can bypass this 
problem by always storing your menu handlers in the main stack script, 
or in the menu buttons themselves.

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