Static objects

[AgentItay]

Hello,
is it possible to somehow create an object (Button, label, etc) that will be visible in all cards of my stack?
Thanks in advance.

[dunbarx]

Hi.

Sure. This is a powerful feature of a property known as the "backGroundBehavior". It applies to groups. Note that even a single control can still be grouped.

Make a new stack. Make three buttons. Group two of those buttons, and in the inspector for that group, set the backGroundBehavior to "true". Now make a new card. The group of buttons appears, but the other one does not, because of the difference in properties.

It is always best to try to plan this sort of, er, behavior early. It is possible to force a control into that state using the "place" command. Look that up in the dictionary, and practice on that single button still sitting at card 1.

Craig Newman

[AgentItay]

Hi.

Sure. This is a powerful feature of a property known as the "backGroundBehavior". It applies to groups. Note that even a single control can still be grouped.

Make a new stack. Make three buttons. Group two of those buttons, and in the inspector for that group, set the backGroundBehavior to "true". Now make a new card. The group of buttons appears, but the other one does not, because of the difference in properties.

It is always best to try to plan this sort of, er, behavior early. It is possible to force a control into that state using the "place" command. Look that up in the dictionary, and practice on that single button still sitting at card 1.

Craig Newman

Thanks Craig, but for some reason when I use:

Code: Select all

on openCard
set the backgroundBehavior of group "testGroup" to true
end openCard

It won't work, and if I put backgroundBehavior in the inspector, it just disappears from the inspector after I close the inspector.
EDIT: Got it working, but only in new cards.... Is there any option to apply this on old created cards as well instead of copying it over and over? I have lots of cards.

[SparkOut]

Yes, you can choose "place group" from the "object" menu in the menubar.

[dunbarx]

Hi.

What Sparkout said, and what I said as well.

It is always best to try to plan this sort of, er, behavior early. It is possible to force a control into that state using the "place" command. Look that up in the dictionary, and practice on that single button still sitting at card 1.

If you are in the middle of a project, and realize that you need to either create a backGround group or change existing controls into such a group, then the "place" command is your friend. I do this regularly. Can you write a simple utility that places an existing group on all cards in the stack? The good news is that once that is done, any new cards now contain it as well.

When I mentioned experimenting, besides that button on card 1, I meant something like this: Make a stack with a bunch of cards. Make a backGround group. Place that group onto several random cards. What happens if you create a new card at various locations within that stack? See what I mean?

Craig

[AgentItay]

Oh, I see what you mean, thanks!
It works perfectly, but do I have to just use the place command for every single card I already have, and set the backGroundBehavior to true for all cards in the future?
For example:

Code: Select all

on PreOpenStack
set the backgroundBehavior of group "group" to true
place group "group" onto card "card1"
place group "group" onto card "card2"
// and so on.
end PreOpenStack

[SparkOut]

Set the backgroundBehavior of the group once, on the group.
On any new cards, you will find the group included automatically without needing any script to place it.
Once you save the stack, the group will remain.
To "catch up" with any cards that were created before you set the group's backgroundBehavior, you need to "place" the group onto the cards that require the group to be added. Again, once placed they will remain after the stack is saved.

[dunbarx]

What Sparkout said again.

But know that when you create new cards, these appear immediately following the card you started from, and only those background groups that were on that starting card will be carried over.

In other words, if you had ten cards, with a backGround group on card 5, and made a new card from card 5, that group would indeed appear on (the new) card 6, but would not appear if you made a new card starting, say, from card 8, or the last card. That is why it is best to plan all this out as early as possible.

But the "place" command rules all, provided you manage it properly.

Craig

[[-hh]]

Hello dunbarx and sparkOut, masters of teaching primary and advanced LC. It's your culprit that I ask now such complicated questions.

Yes, it's simply a question about "the num of...", but reveals as complicated.

I had several problems related to actions that you describe after removing (not: deleting) a bg group from a card.
Is there a predictable behaviour with such groups
= for the num of grps/bgs of a card?
= for the num of grps/bgs of the stack?

Say for example, when I have a stack with one card, then create a new bg group, then create a new card, then remove (not: delete) the bg grp from card 2:
This gives me
the num of grps of this card = 1 (on card 1)
the num of bgs of this card = 1 (on card 1)
the num of grps of this card = 0 (on card 2)
the num of bgs of this card = 0 (on card 2)
the num of grps of this stack = 0
the num of bgs of this stack = 1

When I remove (not: delete) the bg grp also from card 1, the grp is still there, ready for "placing", but
the num of grps of this stack = 0
I can ask for it over the backgroundIDs or the backgroundNames, and I get
the num of bgs of this stack = 1.
The id of this grp is 1010 .
Asking for the owner of grp id 1010 gives "can't find background" and there is grp id 1010 gives false.
While the owner of bg id 1010 gives <the current stack> and there is a bg id 1010 gives true.
The bg is not visible in the ApplicationBrowser and not in the ProjectBrowser.

And the dictionary says group is a synonym of bg.
Is this different counting of bgs and grps a bug or has it a logic I don't understand?

Perhaps something like "a bg-grp is a bg that is placed on at least one card?"

Kind Regards, Hermann

[SparkOut]

Hi Hermann

I think there could definitely be some clarification in the dictionary. In "basic" terms background is a synonym for group, yet "background behaviour" (the property backgroundBehavior) has some things to note. I am sure I remember seeing a brilliant explanation of the whole scenario (including unplaced groups) by Jacque somewhere, whether here or one of the lists, I can't remember.

I will see if I can find a reference/link to it, and if not, I will try and think of something to say at least a tenth as useful as Jacque. Or maybe she might come and repeat herself here, I hope

[jacque]

I hope you find my other response because I don't feel as brilliant today.

In short, bg and grp are almost synonyms if the group is placed on the card. Groups are searched for on the card only (their scope is card based.) Backgrounds are searched for anywhere in the stack, even if they are not placed (stack based scope.) So the number of groups will vary depending on which card is current but the number of backgrounds will remain constant everywhere.

[dunbarx]

Hermann.

I always try to remember to delete (not remove) a group just to keep the object count sane. If I ever wanted to remove (not delete), I would instead hide (not show)

Anyway, this is an option peculiar to groups, that they can be removed but yet still exist; I suppose it has its uses. This is not possible with other controls, which are either there or not there.

Craig

[jacque]

Anyway, this is an option peculiar to groups, that they can be removed but yet still exist; I suppose it has its uses. This is not possible with other controls, which are either there or not there.

It's one of the best ways to store resources, for one thing. I use it all the time. Put all the icon images (or anything else you need to access by reference) into an unplaced group. They are always available, and you don't need an extra card to store them on, which interferes with navigation, or a bunch of hidden objects on any card, or an extra substack that doesn't do anything. Imported HC stacks work this way, all stack icons are put into an unplaced group automatically. You can almost think of it as a limited sort of "resource fork".

There are other uses that aren't as commonly employed. I could imagine creating internationalized groups for each language you want to support, especially if the language needs right-to-left text with different content and differently sized fields and locations to accomodate that. You could place the correct group on the card dynamically so the layout was correct, without needing to adjust every field's text, width, and placement by script.

Edit: This may be the link SparkOut was talking about: http://runtime-revolution.278305.n4.nab ... l#a4654151 Scroll to about the middle of the page.

[[-hh]]

This must be posted again:

There's an order. It's changed a couple of times, but as I understand
it, the system is:

1. Card groups
BackgroundBehavior: false
Shared: no, only appears on one card
Messages:
control -> group -> card -> background(s) -> stack
Event messages: no

2. Shared card groups
BackgroundBehavior: false
Shared: yes, if placed on multiple cards
Messages:
control -> group -> card -> background(s) -> stack
Event messages: no

3. Background groups
BackgroundBehavior: true
Shared: yes
Messages:
Unplaced groups (not on any card): receive no messages
Placed groups, when a grouped control is clicked:
control -> group -> card -> other background(s) -> stack
Placed groups, when clicked outside any control:
card -> group -> other background(s) -> stack
Event messages: yes

Unplaced groups can serve as resource storage for images, icons,
behavior buttons, etc. and can be referenced by anything in the stack.
They are not in the message hierarchy.

Thanks. Very clear and useful.
It explains also again Craig's tip "to be on the safe side, if you don't know exactly what you do".

I wonder why you didn't note the remaining fourth case?
4. Dangerous Background groups
    BackgroundBehavior: true
    Shared: no, only appears on one card
This is a type that can make problems. At least for me: I usually set in inspector BackgroundBehavior to true and remove the "shared" check, because I don't like checks that I didn't make by myself. Will never do that again

Now obviously
the num of bgs counts the above number 3 objects,
the num of grps counts the above number 1-2 objects.
[I couldn't determine uniquely when number 4 counts as grp and when as bg].

Could you please add your listing above to the dictionary in place of the somehow misleading "group is a synonym for background"?

[jacque]

4. Dangerous Background groups
BackgroundBehavior: true
Shared: no, only appears on one card

I don't think I've ever used that combination, but I would expect it to act like any background group in the message path. If I remember right, the Shared option will automatically reset itself if you place the group on a second card.

Could you please add your listing above to the dictionary in place of the somehow misleading "group is a synonym for background"?

The User Notes feature in the dictionary hasn't worked for a long time. Maybe when the documentation effort is farther along it can be addressed.