Group2D attributes

Ok… a GROUP2D is a collection of other “shapes” such as FigureShape (which is a collection of CurveShapes), etc… etc…

Now Group2d has attributes of BORDERCOLOR, FILLCOLOR, etc…

But then so do all the shapes that can be inside a Group2D…

So WHO wins? The Color(s) assigned to the SHAPE? or the Colors assigned to the Group2D? same question for Rotation and Scale for that matter.

Those ‘attributes’ of Group2D (outside of X,Y and rotation) are ignored. They have no effect on items inside it.

Perfect :slight_smile:
Are the rotations added then (Group2D+CurveShape)=actual rotation of the resultant curveshape?
And the same with X,Y the shape coors are offset from the Group2D coordinates?

It seems to me that having the IDE offering to autocomplete a Group2D with things like BorderColor is a bug. No?

I was happy to see these autocompletes because in my use case the ability for a Group2D to apply a color to all the elements would be great. But if it is not going to do anything, well…

[quote=489041:@Robert Livingston]It seems to me that having the IDE offering to autocomplete a Group2D with things like BorderColor is a bug. No?

[/quote]

What back when I found that annoying but thinking about it, I can see what it was was done that way.
It has it because the base class (object2D) has it and Group2Ds need to be Object2Ds to be included in higher level Group2Ds.

-Karen

Ha. I can follow your logic.

The documentation does not say that Group2Ds are Object2Ds but your statement that they [quote]need to be[/quote] makes sense. Normally, the documentation documents that such and such is a member of a class. Not in this instance,

Whatever the case, they should explain that the tempting BorderColor for a Group2D is actually a no go, whatever the reason might be that the IDE has to offer you the option. Lines made up of many CurveShape segments are common in my workspace. They are grouped in Group2D. I would have liked, if I wanted to change the color of the line, to just use the tempting syntax that is offered. Sadly, it not acted upon. The host should not put a cake on the table if you are not allowed to eat it. (Unless they explain that eating is forbidden)

So it should more properly be considered inadequate documentation? :slight_smile:

I refuse to let Xojo off the hook completely. I am a little irritable because I ended up spending a lot of time on this issue trying to understand it.

Actually it does. At the top it says Group2D on the left and “Class (Inherits from Object2D)” on the right.

[quote=489045:@Robert Livingston]So it should more properly be considered inadequate documentation? :slight_smile:

[/quote]

Yes… But I agree they should propagate the property settings on Groups2Ds through the whole tree. Rotation for example does act on the whole group so one would expect the others would too…

As to why it does not work that way, you would have to ask the engineer who designed the feature…

I may be wrong but I think it was Joe Strout, who has not been with the company for a good number of years.

In any case it should not be too hard to write an extension method for Group2Ds that does that.

-Karen

Again you are correct. mea culpa. I probably should shut up.

I am not sophisticated enough to use extension methods, but I can code my way around the problem. And maybe it is time to learn extension methods. :slight_smile:
Thanks, Karen & Greg

[quote=489049:@Robert Livingston]I am not sophisticated enough to use extension methods, but I can code my way around the problem. And maybe it is time to learn extension methods. :slight_smile:
[/quote]

Extension methods are actually pretty straightforward. The method just needs to be in a module and global and defined something like this:

Sub BorderColors(Extends theGroup As Group2D, Assigns theBorderColor as Color)

And can be called like this:
aGroup2DInstance.BorderColors = SomeColor

That is all there is to it.

it’s just syntactical sugar to let you do that instead of something like this:
Sub SetBorderColors( theGroup As Group2D, theBorderColor as Color)

Which you would use like this:
SetBorderColors(aGroup2DInstance, SomeColor)

-karen

Group2D’s have some quirky features. It is not easy to write some generic meaningful change BorderColor method. This problem has nothing to do with Extension Methods.

You can find out how many Object2D’s exist in the Group2D collection with the Count property. But you cannot iterate through them one at a time to change a property like BorderColor. From the Group2D itself, you have no access to the Object2D’s inside. You can remove one at a specified position (RemoveObjectAt). But you cannot, as best I can tell, find out anything about the Object2D at any given position much less change an attribute of one.

To deal with the issue, you might maintain a parallel array of Object2Ds (perhaps in the same class) and insist that all the elements in the Group2D were placed there as members of the array. The Group2D has some kind of “connection” back to the Object2Ds that were put in it. You can change the attributes of one of the Object2Ds in the array. If you do that, you don’t have to do anything else. Because of the “connection” the Object2D in the Group2D (which you might consider to be a pointer back to the member of the array) is appropriately changed and displays as changed.

One thing that is interesting is that it is perfectly possible to add to the Group2D an Object2D that is a variable in some method that does the addition. (AddObject). When that method completes, that variable, declared locally, goes out of scope, and you have no way of referring to it in the future. So its “connected” object in the Group2D has no way of having its attributes changed. There are forever frozen.

It is sort of interesting that the locally assigned variable, itself dead and gone, lives on, as it were, in the Group2D.

When I was dreaming about being able to iterate through a Group2D and change the BorderColor attribute of each member, I thought that it was a feature that if one of those members was, in fact, a Group2D itself, it would cause no problem. Since Group2D’s have a BorderColor attribute, however meaningless, you could assign a color to it and nothing would happen and no error would be generated.

Indeed, if you iterate thought the “parallel” array that you perhaps have created, you can do the simple BorderColor assignment without worrying about whether that particular element was, in fact, itself a Group2D. If it actually is one, no error is generated and nothing “happens”. So in this context, you can consider the fact that a Group2D can be assigned a BorderColor is a convenient feature.

Reader beware: I do not have much experience with all of this. I am relating only what I believe I have seen. I cannot find most of this in the Documentation so I am just sharing what are my impressions.

Karen, I am confused about the “Assigns” word. Is that supposed to be there?

Forget it. I just need to do more experimentation. I don’t see it in the examples under Xojo Extends documentation, but I see some examples elsewhere on the forum that seem to have it.

It looks like the Group2D.Item method does this.

Extends and Assigns are two different things. Extends lets you create a method that appears to belong to a class. Assigns lets you assign a value to a method which is actually passed as a parameter.

[quote=489095:@Paul Lefebvre]It looks like the Group2D.Item method does this.
[/quote]
It does

That is how you traverse the tree to do things like change the included Object2D properties.

-Karen

If you are willing to expose your ignorance, you can get an awful lot of help on this forum. I really appreciate the help of those who volunteer it. One of the problems I have as a solo programmer is that I sometimes find the most contorted ways of doing something and then sticking with it for years because I am unaware of some shortcut. I don’t understand why I never “saw” Item and instead tried to reinvent it.
Thanks, Paul & Karen.