Nothing like diversity. I will think about your recommendation as well as Klaus's. I can see that managing multiple groups can be cumbersome - I think that's how I completely lost a set of buttons. On the other hand, moving buttons around in a group doesn't seem too simple either (Recall that I want to avoid inactive buttons and "holes" in the button bar.) Your ideas about using "covers" and duplicate, overlaid buttons are intriguing though.
Thanks to both of you! -Paul -----Original Message----- From: Scott Rossi [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 3:00 PM To: How to use Revolution Subject: Re: trouble with groups Recently, "Springer, Paul" wrote: > Imagine an application which displays multiple "pages", one at a time, each > contained on a card, to an operator. The operator navigates from page to > page using a set of buttons (treated as a group) which looks the same on all > the display pages. So far so good; just create a group of buttons and place > it on each display page card. (I did not set it as background because there > is at least one page with no buttons). > > Now imagine that you want a different set of buttons for each "kind" of user > (i.e. supervisor, administrator, operator, etc.); some users can see pages > that others can't, and vice versa (assume that inactive buttons are > undesirable). So I thought I would create a different group of buttons (even > though they are copies of buttons in other groups) and try to get the right > buttons to appear depending on who logs in. > > I am struggling with whether to "place" and "remove" the button groups or > leave them on all pages and use "show" and "hide" (the logistics of that are > cumbersome). I have managed to completely lose a button group by some > unknown mistake, so I decided it was time to ask for advice. > > If anyone has any tips that might clarify the use of groups it might help a > lot. For instance, should I be using copies of buttons to make up the > groups, or can an object be a member of more than one group at a time? If > so, I would still need to move them around to fill in around missing > buttons. Or maybe I should forget groups altogether and just hide/show/and > move buttons to get what I need. A single button group is really the best way because you only need to modify one set of controls, as opposed to many. You can show and hide buttons within the group depending on which card the user (operator) is on. You could also place graphic "covers" over buttons within the group to simulate their removal, or simply disable buttons if they're not applicable to the current card. You could move buttons around within the group (if you want to) -- but you can also place duplicates of the same button at different locations within the same group (point their scripts at a single master script to avoid duplicate scripts), and show/hide the required positions as needed. You can hide the button group altogether for those cards for which the group should not be present. This is going to save you a lot of work compared to managing multiple button sets. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design ----- E: [EMAIL PROTECTED] W: http://www.tactilemedia.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution