repeat occurrences of a group

[jim1001]

Is it possible to have:
1) repeat occurrences of a group on a card?
2) a group that appears in different positions on different cards?

The case I have in mind has many occurrences of the group so being able to change one occurrence and have that replicated to all the others is important.

Thanks for any advice.

[FourthWorld]

Normally a group placed on multiple cards will have the same properties on each card, including its rect.

But you could have a preOpenCard handler that sets the group's rect to anything you like before it's rendered.

[jim1001]

But you could have a preOpenCard handler that sets the group's rect to anything you like before it's rendered.

That's a good idea - thanks. That would set it the same for all the other other cards but that wouldn't matter since only one card is in view. I'd just need to set the position in script to that desired for all cards before they're opened.

What about repeat occurrences on the same card - is that possible? It doesn't seem possible to place a second instance of a group on a card in the IDE...

ps: have just started using your Fourth World Scripting Style Guide. Very useful - thanks.

[dunbarx]

Store the desired the rect of the group in a custom property of the card, or use the card number or name to pull a rect from a custom property of the stack. Whatever.

Your desire to create "...repeat occurrences on the same card" actually does not make sense, at least as I read it. A "card" is a native object with certain properties and contains a bunch of controls. An "instance" of a card is really, er, just a card. If you have another card, you have, well, another card.

If you mean to have two "identical" cards, then you can clone one card to create a perfect copy. But the copy is not "perfect", in that the two cards will differ in certain ways, that is, they will have different properies. They will have different numbers and ID's for example, and will be ordered differently.

To make this point, you might design a stack with a single card, and unload (read "hide") and load (read "show") a different suite of controls and card properties every time you "changed" cards. The user would not notice the difference, at least on the surface, but you surely would notice considerable extra effort to manage such a construct.

What does all this mean? Just this: what are you trying to achieve?

Craig Newman

[jim1001]

Craig,

Thanks for taking the time to reply.

For now I’ve found a way around what I was trying to achieve, avoiding the use of groups, but I’m trying to improve my understanding for the future.

I was trying to achieve a set / row of buttons that could be repeated on one card but also could be on more than one card. In my case they were to control playing of different audio files but that’s just an example. The sets would be separated by other UI objects, eg there may be a text box at top of card, then set 1 then an image then set 2 etc. The sets should be always in sync with each other, so for example I make a change to the icon on one button in one place and that is propagated to all sets.

As I understand it, making the set a group would allow me to have one set of buttons on different cards and keep them in sync but wouldn’t allow me to have more than one set on a card.

I can see that for sets on different cards I could play a different audio file by making use of a card custom property. For sets on the same card I don’t know a similar result could be obtained. I know that for any one group you can choose some properties which are not syncd, eg you can choose whether or not to share text for a label field in a group. However when I tried setting a custom property for a group on one card the change was replicated in the group on another card.

Hope this makes sense. As I said I’m exploring possibilities, trying to understand what can & can’t be done & maybe understanding why...

[dunbarx]

If I understand you correctly, you need to learn what the "backGroundBehavior" of a group is.

This property allows a group to exist identically on all cards, copying itself to new cards as they are created (!!). But certain properties may be maintained locally. So try this. In a new stack:

- make a button and a field
- group them, and set the backGroundBehavior of the group.
- In the stack script:

Code: Select all

on opencard
   put the number of this cd into fld 1
end opencard

- Make new cards, perhaps with Cmd-N or from the object menu.

Your group is present on all cards, and the contents of the field are local to each card. This field property can be changed as well, if you play around with its "sharedText" property.

There is nothing preventing you from modifying the way the group looks or acts as you navigate from card to card. You can change its loc, for example

Code: Select all

on opencard
   set the top of grp 1 to 100 + random(100)
end opencard

and that property will stick unless you change it again. Play around...

Craig

[jacque]

What about repeat occurrences on the same card - is that possible? It doesn't seem possible to place a second instance of a group on a card in the IDE...

Right, you can only share a group once per card. The only workaround I can think of is to place the group once during development and then use the preopencard handler to clone it and position it as many times as you need per card. On closecard, delete the clones.

[dunbarx]

It doesn't seem possible to place a second instance of a group on a card i

Again, what is the difference between a copy of a group and a "second instance" of that group? In other words, what Jacque said, sort of...

I suspect the issue here is purely semantic. Can you tell us the distinction in your own mind? In other words, is there a case where what you require is not implemented with a simple copy?

Craig

[jacque]

I think I know what he means. He wants a group that can be shared as many times as neccessary on a card. I.e., many instances of the same group that behave just as backgroundBehavior does, only more than one per card.

In LC we are limited to one instance of a shared group per card rather than multiple instances. LC has behaviors that can be shared among any number of controls no matter where they are located, but behaviors are script only and in this case he wants the actual controls to be shared. This would allow edits to the actual controls to be updated by changing only one of them. As it is now, we need to duplicate the group and apply changes to each clone individually.

This would be a good feature request.

[dunbarx]

I.e., many instances of the same group that behave just as backgroundBehavior does,

Um, right. But what is the difference between many instances and many copies?

And if this never need be duplicated among cards, but only within a single card, then your original post recommending simple copies would do fine, and backGroundBehavior never enters into it. But the original post mentioned both.

I suspect that showing and hiding either groups or controls within groups is what is wanted. And if several groups need to be grouped, with the backGroundBehavior of the superGroup being set, then one can still hide of show subgroups as needed

Craig

[jacque]

I.e., many instances of the same group that behave just as backgroundBehavior does,

Um, right. But what is the difference between many instances and many copies?

An instance is not a copy. Copies, as you mentioned, have different IDs, must be edited individually, are not shared, and increase the size of the stack. Instances are reflections of the original master, exist in RAM only, do not require additional stack size, and changes to any instance are replicated across all instances.

Groups with backgroundBehavior are instances. There is only one "real" copy in the stack and it is reproduced in RAM on every card that shares that group. Changes to the group on any card are replicated on all cards that share the group.

Groups without backgroundBehavior are copies and must be edited individually. The OP wants multiple instances per card that behave as backgroundBehavior does now, reflecting the same "real" group.

[jim1001]

Jacque - thanks for explaining it eloquently for me. That is exactly what I was getting at in point 1) of my original post. I was also looking at the clone command as an option before seeing your post.

Craig - thanks for your help, advice & ideas. You’ve made me aware that I can change group properties dynamically by script and even though that would change all cards that share the group, only one card with the group would normally be on view at a time.

(From the LC dictionary I can’t see much difference between clone or copy when it comes to cloning (or copying) a group. Anyway, if clone works that'll do for me!)

Thanks everyone for your thoughts.

[jacque]

(From the LC dictionary I can’t see much difference between clone or copy when it comes to cloning (or copying) a group.

Cloning is just a shortcut for "copy and then paste" with the added benefit that it doesn't change the clipboard. Also the new clone can be referred to as "it" immediately after the operation:

Code: Select all

clone button 1
set the name of it to "myClone2"

Note that "it" is fragile and temporary so don't expect its value to last very long. Lots of commands populate the "it" variable.

[jim1001]

Cloning is just a shortcut for "copy and then paste"

Of course (now you've explained it!) That's a good way to think of it. I should have been able to work that out but thanks for indulging my laziness.

Thanks for the rest of the explanation too.

[FourthWorld]

Not sure if/when this will ever see the light of day, but there's a long-standing request to have a Viewer object like another xTalk (Gain Momentum) used to have, which would let you display another stack within a rectangle in any other stack:
http://quality.livecode.com/show_bug.cgi?id=2786

In the meantime, cloning groups is your best bet for now.