[Use-revolution] Re: adding objects to groups (Rev bug)

[Ben Rubinstein]

Thanks all for their replies.  To add an existing object to an existing
group (to add a new object you can either use 'create x in group y' as andu
suggested, or edit the group before creating the object as Jack noted) you
have two choices: 
    - set relayerGroupedControls to true and move the object up or down the
layers to enter the group
    - when you ungroup some objects, the details of the group are
remembered; when you make a new group in the same session, it is actually
made with the properties of the old group, including name, id, and script.

Small documentation note on the first approach: the documentation observes
that you can use relayerGroupedControls to take an object out of the group,
but doesn't mention the reverse:

    "If the relayerGroupedControls is true, you can move a control
    out of a group by setting its layer to a number greater than
    the topmost control in the group, or less than the bottom-most
    control in the group."

Small implementation note, related to the second approach: this no doubt
works fine if you ungroup, reselect, regroup.  However if used more loosely,
or even if you weren't trying to use this feature at all, but just unselect
a group one place, then go somewhere else and make a new group, it can upset
Revolution more than somewhat, to the point of corrupting stacks.

Recipe:
    - launch Rev
    - make a new mainstack
    - add two buttons
    - group them
    - ungroup them
    - make a new mainstack
    - add three buttons
    - attempt to group the first two

Result: a group with the same id (1005) as the third button.  If you try to
look at this stack in the App Overview, you'll get errors.  If you save this
stack, quit Rev and relaunch+load, you'll find it is an interesting state.
It appears to have only one button; 'the number of buttons' may return 2 or
4; the details of button 1 may be identical to button 2; etc.  You've
certainly lost the first two buttons.  In principle I'd have thought this
could result in genuine loss of work.

So it looks like this is a handy feature (that details of the last removed
group are remembered) which needs a small additional bit of error trapping,
to not restore the old id (or perhaps not restore the old group info at all)
if that id is already in use.

  Ben Rubinstein               |  Email: benr_mc at cogapp.com
  Cognitive Applications Ltd   |  Phone: +44 (0)1273-821600
  http://www.cogapp.com        |  Fax  : +44 (0)1273-728866