Re: Groups: Bugs and features ("last group" broken)?

[Mark Schonewille]

Yup! The owner is the solution. I just ran into the very same problem  
and not knowing which group has been created, I can use the owner of a  
grouped object, because I know which objects have been grouped :-) The  
other issues don't seem to affect me that much at this moment.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
http://economy-x-talk.com

Submit your software at http://www.quickestpublisher.com

On 16 sep 2009, at 21:54, Wilhelm Sanke wrote:

Thanks for the confirmation of one of the group issues I listed in  
my post. I must have missed the thread in May being out of office  
and country at that time.


Using Scott's "templategroup" proposal may be handy when only one  
group building is involved.


In the case of my "Gradient Kaleidoscope" scripts I have to make  
frequent use of grouping and ungrouping (the last group) of images,  
and I find it easier and more convenient to use the workaround with  
finding the "owner" of one of the controls that have been grouped,  
as in -  I quote myself here -


"select fld "one" and fld "two"
group
put the owner of fld "one" into tlastgroup"


Best regards,

Wilhelm Sanke


___
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

Re: Groups: Bugs and features ("last group" broken)?

[DunbarX]

Wilhelm:

Workarounds. That is one of the endearing things about Rev.

I still like the templateGroup method, where, for example, you could set 
the name of each new group to some text (like "groupNumber") appended with the 
number of groups plus 1. So the last group of 15 would be:

group "groupNumber15"

This ties up the name of the templateGroup, of course.

Ken Ray suggested trapping the "newGroup" message. I suppose you could use 
this to set a property or the group name, similar to the templateGroup 
scenario.

Any of these can get you any group you need, just querying them all.

Craig Newman

In a message dated 9/16/09 3:55:02 PM, sa...@hrz.uni-kassel.de writes:


> In the case of my "Gradient Kaleidoscope" scripts I have to make
> frequent use of grouping and ungrouping (the last group) of images, and
> I find it easier and more convenient to use the workaround with finding
> the "owner" of one of the controls that have been grouped, as in -  I
> quote myself here -
> 

___
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

Re: Groups: Bugs and features ("last group" broken)?

[Wilhelm Sanke]

On Wed Sep 16, 2009, DunbarX at aol.com DunbarX at aol.com wrote

Yes, I ran into at least one of your issues back in May. Check out the 
"New

groups bugaboo" thread in the archives.

Eventually I was led to a very cool feature (by Scott Rossi), the
"templateGroup". Check this out. It is very stable. This is something 
solid; using
the somewhat ephemeral "last" keyword as a hard tool always seemed 
like a very

cute, but a little dishonest, methodology.

Apparently this is only a problem with groups. The "last" keyword works
fine with, say, buttons.

Craig Newman


Thanks for the confirmation of one of the group issues I listed in my 
post. I must have missed the thread in May being out of office and 
country at that time.


Using Scott's "templategroup" proposal may be handy when only one group 
building is involved.


In the case of my "Gradient Kaleidoscope" scripts I have to make 
frequent use of grouping and ungrouping (the last group) of images, and 
I find it easier and more convenient to use the workaround with finding 
the "owner" of one of the controls that have been grouped, as in -  I 
quote myself here -


 "select fld "one" and fld "two"
 group
 put the owner of fld "one" into tlastgroup"


Best regards,

Wilhelm Sanke

___
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

Re: Groups: Bugs and features ("last group" broken)?

[DunbarX]

Yes, I ran into at least one of your issues back in May. Check out the "New 
groups bugaboo" thread in the archives.

Eventually I was led to a very cool feature (by Scott Rossi), the 
"templateGroup". Check this out. It is very stable. This is something solid; 
using 
the somewhat ephemeral "last" keyword as a hard tool always seemed like a very 
cute, but a little dishonest, methodology.

Apparently this is only a problem with groups. The "last" keyword works 
fine with, say, buttons.

Craig Newman
___
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

Groups: Bugs and features ("last group" broken)?

[Wilhelm Sanke]

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


 in the text 
brought up on the menu card from the topright introduction butt