The best way to avoid the issue is to always create your menubar
first in new projects.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
\
That's good advice, but it's a workaround, people often don't develop
in xTalk that way.
I KNOW the classic building methods; Write it out on paper,
flowchart, bottom up, plan everything.
But it's hard to plan methods that may not work or be more efficient
than others, or the specs might evolve during the project, or down
the road one gets a better insight on what it is the client really
wants after working with the data.
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.
In my project, if I had done the menus first, I'd be changing them
all the time.
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.
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.
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?
--
stephen barncard
s a n f r a n c i s c o
- - - - - - - - - - - -
_______________________________________________
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
