Menus Driving Me Nuts!

[MisterX]

if my way and experience can help then i hope it does... 

in multicards, the root of the hierarchy is the stack, then the background,
then the card - then the group or what it's the card out of the background -
including other background groups. Inmensely flexible but in the raw ;)

However with backgrounds, in RunRev and MetaCard, as soon as you add
something to a card, the next card you create from that card will "inherit"
the extra stuff (when they are "shared" like buttons or "background" like
groups. But it's disconcerting since existing cards dont inherit the
background behavior of other groups equaly shared... 

begs the question if they have the same number of cards - false but they
share the same "screen" contrary to the older hypercard - here you would
create different cards, put the bgs into them and then you have what you had
in HC - structuraly speaking - Rev is a structure powerhouse!

So the easiest solution is to make one front end for your data and store
your data into a file or another hidden substack. Then your one card, will
never be out of synch with the data. That's the easiest way!

Not the fastest

Cards are too cool too ignore though - thanks to their local behavior - but
be careful to change ONE group, not many. Put the menugroup into a
comprehensive "objects" group and your troubles will always be shared across
all your cards or improve that quickly! ;)

did that make sense?

Cheers
Xavier
http://monsieurx.com/

> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of 
> SimPLsol at aol.com
> Sent: Monday, June 27, 2005 20:31
> To: use-revolution at lists.runrev.com
> Subject: Re: Menus Driving Me Nuts!
> 
> Peter,
>      I share your menu misery.
>      When they work, as they seem to for most people in most 
> situations, they really are brilliant. When they don't 
> work....(colorful/colourful language deleted).
>      A couple things I've learned:
>      Adding menus to a multi-card stack creates problems. If 
> at all possible, add menus before adding cards.
>      Don't put menus in the background group. It seems 
> logical, particularly if you are adding a new menu to a stack 
> with cards, why not just put the menu in the background group 
> to have it appear on all of the existing cards (it will be 
> automatically placed on any new ones) - but, don't do it. 
> Copying the menu group card to card is also, in my 
> experience, unreliable - better to create a new one card 
> stack with the new menu (or delete the existing stack down to 
> one card) and import the data to the new cards.
>      As for the height. If you the above fixes don't help and 
> you have to "hard wire" the height, set it in an openStack 
> handler - seems something happens to the stack height after 
> the preOpenStack message is sent.
>      Many times I've said "There must be a better way." And 
> people have come up with clever workarounds but, as far as I 
> know, none are well documented.
> Paul Looney
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage 
> your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>