Undisplayed Groups

[sritcp]

From 2005 Scripting Conference tutorial:
"Groups can be displayed on a card, or used simply to store objects or scripts for reference by other scripts and objects. ...........
Groups which are not placed on any card will never be seen, but their contents can still be accessed"

1. If a group (and the objects it comprises) are never placed on a card, how are they created in the first place?

2. Under what situations would we use such undisplayed groups? i.e., what would be the advantage over placing them on an (unused) card?

Thanks,
Sri.

[Klaus]

Hi Sri,

From 2005 Scripting Conference tutorial:
"Groups can be displayed on a card, or used simply to store objects or scripts for reference by other scripts and objects. ...........
Groups which are not placed on any card will never be seen, but their contents can still be accessed"

1. If a group (and the objects it comprises) are never placed on a card, how are they created in the first place?

Voodoo!

Of course someone (or a script) has to create the group and remove it from the card!

2. Under what situations would we use such undisplayed groups? i.e., what would be the advantage over placing them on an (unused) card?

Good question!
Not much, if at all, I think.

Maybe this is more a psychological thing...


Best

Klaus

[sritcp]

Hi Klaus:

I am familiar with, may be, 5% of LiveCode. Yet, with that little, I was able to write a fairly intricate (to me) app in about two weeks.

So, yes, LiveCode is voodoo!

Sri.

[Klaus]

[dunbarx]

I think this is more of a situation one finds oneself in, rather than one creates.

You might make a group and then for whatever reason, delete the objects in it. This has happened to me. You still have the group. It is an object that has no parts, unlike a button, say, that is merely hidden.

It is a physical analog to an empty variable. It lives, is not hidden, but is empty.

This might be a useful thing. I just cannot think of a good reason at the moment.

Craig Newman

[jacque]

2. Under what situations would we use such undisplayed groups? i.e., what would be the advantage over placing them on an (unused) card?

Usually it's done to store resources like images, icons, cursors, buttons that contain behavior scripts, or anything else that is referenced indirectly. The objects could easily be stored on an unused card, but sometimes an extra card gets in the way. For example, you'd have to work around it if you have a "go next" button because you'd never want users to see that card. If any scripts need to check something on every card, it needs to make an exception for the unused one. If any scripts need to repeat an action for "the number of cards" then the script will always need to subtract one if it only wants to work with the user-accessible cards.

To create an unplaced group, just group all the objects and then remove the group from the card. I do this frequently to store icon images, for example.

[sritcp]

Thanks, Jacque, that makes sense (although many of these nits could be avoided just as well by storing the group in a substack).

Another question: How would one access the group that doesn't show up anywhere? For example, where would it appear in the Application Browser?

Thanks,
Sri.

[jacque]

Unplaced groups are accessed by script just as though they were placed, though you need to use the "background" designation. I.e.:

put there is an img "iconImage" of bg "unplacedGrp"

They do not show up in the app browser. If you want to see them there, or add/remove objects, place them temporarily on a card. When you're done, unplace them again. Alternately you can do most things from the message box too if you want to type commands, for example:

copy img "newImage" to bg "unplacedGrp"

You're right you could use a substack instead and many people do. I prefer to keep extraneous stuff out of my projects but there's no good reason for that. For me it keeps the overview cleaner.

[dunbarx]

Jacque.

Learn something every day.

A group that is removed from a card is "reduced" to a backGround. That backGround, placed back onto that card, becomes, again, a group.

I only ran across this sort of thing when I denuded a group of its controls, and noticed that the group still lived on the card. This is entirely different than what you meant, that you can have a bg (not a group) filled with stuff, invisible, and a good place for resources, as you say.

But it is disconcerting that the application browser does not show this. It seems to ignore backGrounds. The one place to go to in order to view the objects on a card, and it just does not care to. This seems like a deficiency. If you are ever wondering where your resources were, and forgot that there was an unplaced bg, you would get no help from the browser.

This is worth mentioning as a feature request.

Craig

[sritcp]

They do not show up in the app browser.

This is worth mentioning as a feature request

The App Browser could have another category under each stack, in addition to Audio clips and Video clips: may be, call it "Ghost Objects" (as opposed to Hidden)?

Sri.

[jacque]

True, the app browser only shows objects that are on cards. You can see all the groups in the stack, placed or not, in the Object menu's Place Group menu item.

A group that is removed from a card is "reduced" to a backGround. That backGround, placed back onto that card, becomes, again, a group.

This mental model might confuse new users, since a "background" is still a group. For future readers: There are two types of groups: background groups and card groups. The most significant difference is where they are layered in the message hierarchy. Card groups are, of course, those that are placed at the card level. Since an unplaced group is not on any card, it is a background group. If you place it on a card, it will still be a background group if its backgroundBehavior is set to true; otherwise it will be a card group.

Any background group that is not on the current card must always be referred to as "background", whether it is unplaced or not. That's why you can query "the number of backgrounds" and get all placed background groups in the stack, but asking for "the number of groups" will only give you the number of groups (of either type) on the current card.

Some of this admittedly confusing syntax is for HyperCard compatibility. Some of it is useful for distinguishing groups with backgroundBehavior from those without it.