trouble with groups
paul.springer at sensis.com
Wed Apr 21 14:12:31 CDT 2004
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!
From: Scott Rossi [mailto:scott at tactilemedia.com]
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,
> 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
> the display pages. So far so good; just create a group of buttons and
> it on each display page card. (I did not set it as background because
> is at least one page with no buttons).
> Now imagine that you want a different set of buttons for each "kind" of
> (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
> though they are copies of buttons in other groups) and try to get the
> 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
> 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
> 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.
Tactile Media, Multimedia & Design
E: scott at tactilemedia.com
use-revolution mailing list
use-revolution at lists.runrev.com
More information about the use-livecode