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 | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
