Group problem . . .

[richmond62]

If one creates a group, does something with it, and then ungroups it: and then, subsequently groups some other objects . . .

Let's suppose I have an image with a field overlaying it:
-

Screenshot 2025-03-04 at 12.05.39.png (77.28 KiB) Viewed 5254 times

-
And then GROUP those 2 objects, and call the group "XXX":
-

Screenshot 2025-03-04 at 12.08.28.png (127.24 KiB) Viewed 5251 times

-
Then import a snapshot from that group:
-

Screenshot 2025-03-04 at 12.10.18.png (113.7 KiB) Viewed 5248 times

[richmond62]

Then ungroup the group:
-

Screenshot 2025-03-04 at 12.10.39.png (119.49 KiB) Viewed 5247 times

-
Now, suppose I want to group some other objects:
-

Screenshot 2025-03-04 at 12.14.01.png (108.9 KiB) Viewed 5247 times

-
This is what happens:
-

Screenshot 2025-03-04 at 12.15.14.png (97.57 KiB) Viewed 5246 times

-
Which is, frankly, utter crap.

[richmond62]

To ensure that this does NOT happen one has to do this prior to grouping the new objects:

one has to group some random object:
-

Screenshot 2025-03-04 at 12.19.31.png (107.02 KiB) Viewed 5240 times

-

Screenshot 2025-03-04 at 12.17.09.png (125.6 KiB) Viewed 5245 times

-
BEFORE selecting and grouping any new objects.

[richmond62]

groupies.png (220.63 KiB) Viewed 5232 times

-
NO; not like that at all: more's the pity.

[tperry2x]

Thats.... odd.
I'll try and replicate your steps and see if I can reproduce that bug here.

[tperry2x]

If one creates a group, does something with it, and then ungroups it: and then, subsequently groups some other objects ...
Let's suppose I have an image with a field overlaying it

Check. Done that.

A.png (194.93 KiB) Viewed 5181 times

And then GROUP those 2 objects, and call the group "XXX":

Well, I called the group something else, but shouldn't make any difference (?)

B.png (157.05 KiB) Viewed 5181 times

Then import a snapshot from that group:

Done:

C.png (141.56 KiB) Viewed 5181 times

Then ungroup the group:

Okay:

D.png (156.63 KiB) Viewed 5178 times

Now, suppose I want to group some other objects:

Done:

E.png (177.98 KiB) Viewed 5178 times

This is what happens:
Which is, frankly, utter crap.

Nothing is disappearing, seems to be working as expected.

[richmond62]

That problem is persistent across my MacOS 12 and my MacOS 15 machines: and is present with LCC 963.

[tperry2x]

That problem is persistent across my MacOS 12 and my MacOS 15 machines: and is present with LCC 963.

Hmmm, if I get the chance today, I'll try on a MacOS 12 machine.
Obviously, as per my screenshots, I was testing this in Linux. Haven't had a chance to see if this is also present in Windows yet. I will try to check that out at some point.

[richmond62]

BUT does not happen with LCC 8.1.10 (just tested on MacOS 12).

[tperry2x]

BUT does not happen with LCC 8.1.10 (just tested on MacOS 12).

Also interesting... So, back to LCC 8 as our engine then? (only half joking).

[richmond62]

Well, at least 'sideways' to somewhere between 8.1.10 and 9.6.3.

Certainly NOT a show-stopper, just a pain-in-the-bum.

[axwald]

Can report occasional strange occurrences with grouping, even back in LC 6.7.10. This includes different groups switching names, groups moving clandestinely into other groups, and, yes, vanishing of groups after modifying a supposedly unrelated object.

Since this only happens quite rarely I haven't been able to reproduce this. I suspect this happens most often when:

• a stack isn't rebuilt for some time, and its "revBowels get twisted".
• a stack has too many groups, or
• groups are too deeply nested.
• "Project Browser", especially (but not exclusively) when used to move groups or grouped objects quite frequently messes everything up.
• "Project Browser" AND "Application Browser" (revApplicationOverview) TOGETHER are a sure road to damnation.

So that's what I do to not get bitten this often:

• I avoid, whenever possible, to group more than 5 levels deep.
• And I only group persistently what's really necessary.
• Before any "grouping session", I save.
• With each new version, I "Save as", and use the ancient "revAltCleanStack" by Chipp Walters.

This helps for a good mood & happy coding.

Final words: Furthermore, I think that XTalk must be built on LC 6.7.10. ;-)

[tperry2x]

All very interesting to note, and good tips.
I particularly like this part though:

Final words: Furthermore, I think that XTalk must be built on LC 6.7.10.

That's great for Windows and Linux, shame about MacOS though.