LiveCode Forums.

Hi,

One of the results when copying or moving controls between stacks is that Livecode usually (always?) assigns them a new ID number. This renumbering can cause issues with behavior buttons and image assignments . However, I have just had it pointed out to me that if the control, e.g. a button, is on a stack that is cloned then it retains it's original ID. I can see the logic as the copy of the stack will have a new name so the object references will be unique.

I wonder if anyone has ever seen a control given a new ID as the result of a clone operation? I'm asking the question because while I trust my source I do not trust my understanding of what he sent me.

Simon.

I made two new stacks and put a button on one of them. ID was 1003. I copied the button and pasted onto the other stack. Button there was also ID 1003.

I deleted the button on the second stack, and went back to the first stack. I copied the button again, and pasted as before. Copy was ID 1004.

Repeated the process. The new copies had ID's 1005, 1006, etc.

Deleted both stacks and made two new ones. The above action repeated itself, that is, the FIRST time I copied, the ID's stayed the same.

When I delete only the second stack, and then paste into a new one from the first, the ID of the copy holds at 1003. So the second stack, if it ever had a button, "remembered" that, and reserved that ID.

Craig

Hi Simon,

This renumbering can cause issues with behavior buttons

To avoid this, i usealy the name of btn to define behavior of controls with a script on preopenstack.
There is also altID but i never used it but it is maybe useful in your case
Best regards
Jean-Marc

Cloning stacks and copying controls are very different operations. I haven't seen a cloned stack alter the IDs of the controls within it, but we would expect any copied control to have its ID changed.

It may help to keep in mind how IDs are assigned: the ID property of a stack serves a unique role, different from other object IDs. In all other objects, its ID property is used to uniquely identity the object. Stack objects are identified by name; the ID property of a stack serves only as storage for the next available ID for other objects within it. As an object is created within a stack, the stack's ID is used as the ID of the new object, and the stack's ID property is incremented. This central place for next available ID keeps object creation from having to look through all objects to determine the next available ID.

With that in mind, we can appreciate how cloning an entire stack will preserve IDs, while cloning or copying any other object within a stack may necessitate changing the new object's ID to avoid conflict with existing objects.

When I delete only the second stack, and then paste into a new one from the first, the ID of the copy holds at 1003. So the second stack, if it ever had a button, "remembered" that, and reserved that ID.

Actually, the first control of a new stack is always 1003 so nothing is remembered, just as the first card of a new stack is always 1002.

A better test is to copy a control from one stack and paste it into another stack that already has many of its own controls. The pasted control will have the next ID in sequential order.

Jacque.

Simon originally asked:

I wonder if anyone has ever seen a control given a new ID as the result of a clone operation?

The answer is "yes", unless that clone is pasted into a brand new stack that, of course, never had any controls. In that case, as you say, the new stack simply applies "1003" to its new child, perhaps the same as the original.

But I believe that the issue Simon is on about is controls with the same ID in any situation at all, perhaps especially with behaviors. The answer here is "yes" as well, and so one must be careful to remember the fact that any duplicate ID's in a project are in controls that live in different stacks. This is how it has always been.

Craig

EDIT:

For learning, it might be important to know that a stack will not assign a lower ID for a new control even if that ID is "available", that is, a control that has since been deleted was originally assigned that number. This is a good thing.

I have just made a very silly stack called "sillyCLONE"
with a single button 'CLONE' and as single field 'fBTN" on a card.
- -
The button contains this script:
Every time one clicks on that button it clones the card with the button and the field: each time the
button and the field are given new IDs.

OBVIOUSLY this is NOT stack cloning, it is card cloning.

Richmond.

People are constantly interchanging, in error, "silicone" for "silicon". Drives me nuts.

I have never seen anyone go so far out as "sillyClone".

Craig

dunbarx wrote: ↑

Wed Jun 24, 2020 7:42 pm

Richmond.

People are constantly interchanging, in error, "silicone" for "silicon". Drives me nuts.

I have never seen anyone go so far out as "sillyClone".

Craig

That was NOT in reference to either silicon or silicone; it didn't even cross my mind; just had to think of
something to call that stack.

-
The lips are to keep Craig happy.

[Thought that b**bs might be "pushing things too far."]

https://youtu.be/z-znH5v2Pqg

Seems that buttons do retain their ID numbers.

Although, personally, I always stick with the name of an object, even when referring in a way that requires the ID:

That was NOT in reference to either silicon or silicone; it didn't even cross my mind; just had to think of
something to call that stack.

Richmond.

Baby.

I knew that.

Craig

Richmond.

Baby.

I knew that.

Craig

Craigie-waigie, nobody has called me "Baby" for years . . . we could take this further if only . . .

Ignoring the last few divergent posts thank you all for an interesting debate.

My point of interest in IDs comes from creating a palette stack that stores custom controls for use in the IDE. Typically these are groups that also use a behavior button which may be either part of the group or external to it.

If your great custom control uses both images and behavior buttons then a few hoops have to be jumped through when the components are copied to a project stack as the behavior button and images will have new IDs. So not only does the behavior of the group have to be updated to point at the copy of the behavior button, the code also needs to determine the ID number allocated to the copy of the behavior button.

I have developed one version that conducts searches for the name of the behavior button but I am aware that button names are not unique.

I am looking at designs of the palette stack that use sub-stacks that are cloned instead of copied as a method of preserving the group behavior links when the group controls are added to a project stack.

phew - I hope that makes sense - its been 32 degrees here which is hot for a celt so thats my excuse if I have just typed drivel

Just give your custom controls names,
then you shouldn't have to fuss about ID numbers at all.

richmond62 wrote: ↑

Thu Jun 25, 2020 7:45 am

Just give your custom controls names,
then you shouldn't have to fuss about ID numbers at all.

If only it was that simple, the problem is with behavior buttons and to a lesser extent images. Looking at behaviors lets say that I name my group control smkPickList. This control will probably only be used once in a project so its code is stored in a behavior button inside the control's group

Lets say that when the master copy is on the palette tools stack, named stack "ToolsPalette" its behavior is stored inside the group and has a name of "smkPickListBehavior" and an ID of 1023.

The palette stack allows dragging and dropping of group "smkPickList", but its just a copy and paste action. When a copy is made say to stack "Project" the control group is allocated a new ID and so are all the controls inside the group. Inspecting the copy of the group in stack "Project" will show that its behavior pointer is still set to button ID 1023 of stack "ToolsPalette" and worse the ID of the button "smkPickListBehavior" inside the copy of the group will now have a new ID number because it is now on a new stack.

At the moment my code reads the ID of the original behavior of the group, determines the name of the behavior then searches for the name of the behavior button in the project stack and then resets the group to use the local behavior. It all works as long as the button names are unique.

It also works with behavior buttons stored outside the group in a similar way.

Images : if the group control assigns images to buttons then there are problems as the image will most likely be allocated new IDs breaking the allocations made in your original control group. This means that code similar to this has to be employed : This is called using the newGroup message (thanks Bernd). Again it relies on control names which are not unique but at least it is reasonable to expect the images to be within the group.

So its all a bit of a fuss.....