I will discuss a number of peculiarities concerning groups.
1. "last group" is broken, at least it is unreliable
2. Rev remembers group names, even after you have ungrouped a group
3. If you select controls and group them by script the handles of the
group are shown
4. You cannot paint on an image when it is grouped
5. Groups belong to the factors in an already reported scenario for
safely crashing Rev
1. "last group" is broken, at least it is unreliable
From the dictionary
"Tip: To refer to the newly-created group, use the last keyword:
group button "Yes" and button "No"
set the name of last group to "Do It""
Unfortunately, this is no longer the case - or has never been?. "last
group" may indeed still refer to newly created groups, but there are a
number of scenarios where this does *not* apply.
One example:
Create a group consisting of two graphics. Then create two fields and
run the following script:
"on mouseUp
select fld "one" and fld "two"
group
put the name of last group
end mouseUp"
You will get the name of the group of graphics, not that of the fields!
Conclusion:
If the topmost group consists of graphics and that graphics' group is
also on the top layer, then a newly created group of fields will not be
the "last group" - although it may be even placed on the top layer.
This bug is apparently also the cause for sometimes creating nested
groups up to 9 levels deep, a phenomenon I had mentioned in my last
crash report "How to reliably crash Rev 3.5 and 4.0-dp3 with four script
lines".
Workarounds:
To be on the safe side, I have rewritten my relevant scripts using the
"owner" property, like
"on mouseUp
select fld "one" and fld "two"
group
put the owner of fld "one" into tlastgroup
end mouseUp"
Another, more circumstantial, workaround would be to use the "newgroup"
keyword in an accompanying card script:
"on newgroup
global glastgroup
put the name of the target into glastgroup
end newgroup"
and then refer to the global "glastgroup" in your button script.
========================
2. Rev remembers group names, even after you have ungrouped a group
Example: Create two fields, group them, and give the group a name. Then
ungroup this group.
If you now - or at a later time - group these same two fields again,
they will automatically get the name given to that group the first time.
Interesting "feature", what purpose would it serve?
========================
3. If you select controls and group them by script the handles of the
group are shown
If you are in "pointer tool" mode it is convenient to see the handles of
controls and groups in order to be able to select and manipulate them
manually, but if you select and group in a script you do not need this
"help", it is a nuisance at best.
Although you are in "browse tool" mode when you run the script
" select fld "one" and fld "two"
group"
the handles of the group will be shown. If you would like to take a
snapshot of the newly created group ( "(rect of group tlastgroup) of
this card"), this snapshot would include the handles.
Workaround: Add two lines to the script
" select fld "one" and fld "two"
group
choose pointer tool
choose browse tool".
The same holds for the ungroup command.
==========================
4. You cannot paint on an image when it is grouped
This is a bug - or feature? - that has already been discussed several times.
If you want to paint on a grouped image by script - for example using
the "drag" command - you have first to move the image out of the group
and then later put it back into the group, like in
"on mouseUp
set the relayergroupedcontrols to true
put the layer of img "x" into tlayer
set the layer of img "x" to top
send "mouseup" to btn "drag on image x"
set the layer of img "x" to tlayer
set the relayergroupedcontrols to false
end mouseUp"
Applying the global property "selectGroupedControls" or the new group
property with the same name "selectGroupedControls" (introduced in Rev
3.5) does not make a difference, at least I did not succeed in putting
together another workaround.
================================
5. Groups belong to the factors in an already reported scenario for
safely crashing Rev
I have described this in detail in my recent post to this list "How to
reliably crash Rev 3.5 and 4.0-dp3 with four script lines". Here I just
point out that "group" is among the elements causing to crash Rev and
refer you to my original post for more details.
The following script assumes that you have set the angle of img "test"
to an angle other than 0, that img "test" is ungrouped, and that img
"Test" belongs in the category of "Pre-PNGs".
"lock screen
select img "Test"
group
set the angle of img "Test" to 0"
For the definition of "Pre-PNGs" see my above-mentioned post or the
introduction to my stack
<http://www.sanke.org/Software/MoreAboutMasksRev3.zip> in the text
brought up on the menu card from the topright introduction button.
========================
Seems to me, there is some work to do from the side of the Rev
developers. I hope I have contributed something to start with.
Best regards,
Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
