How many objects (IDs) can be generated by script?

[Havanna]

ID in Livecode is unique andc persistent.
For some purposes I need to create numerous fields at runtime and the field IDs are in the 80.000s
Does anybody know if there is a Limit to the ID?
if so then
When is it reached?
What will happen there?
Is there any way to go around the problem?
end if

[Klaus]

Hi Havanna,

find this and more info at the same place as described here:
http://forums.livecode.com/viewtopic.ph ... 05#p113683

Best

Klaus

[Havanna]

Thanks, Klaus,

I had noticed that, since it was an answer to my own post.
I'm still not sure as to what this means in repect to the question of highest possible Object ID:
the script creates a number of fields (depending on database output) in a group and deletes those fields after use.
It would be interesting to know how to get around a possible failure at some point in a standalone.

[dunbarx]

Hi.

I believe that the number of objects, whether in a group or on a card, is unlimited, within the available memory of the machine, and therefore implies that the maximum ID is not an issue.

Numbers are cheap. Objects on a card do take, however, resources from the engine. But if the second is not a problem, then the first should be easy.

Craig Newman

[Havanna]

Numbers are cheap. Objects on a card do take, however, resources from the engine. But if the second is not a problem, then the first should be easy.

Well, that sounds promising, thx

[[-hh]]

Klaus meant the "unlimited" note, given in the User guide pdf; ID's are not especially mentioned there as "limited".

A number of available IDs that is guaranteed may be concluded from the highest number mentioned and from the 'reserved ranges' in the docs to entry "ID". From that there are at least 196999 short IDs free for your own use. Presumably they use 32 Bit for that, so you can even safely use ID's of length 7-14. Just try (I never had more than 2048 objects on one card). Don' forget, the height and width of stacks are limited

If you intend to create a lot of objects 'on the fly', please add a benchmarking script and your timing and machine info to the IDE benchmarking project (subforum IDE contributors).

[Havanna]

If you intend to create a lot of objects 'on the fly', please add a benchmarking script and your timing and machine info to the IDE benchmarking project (subforum IDE contributors).

Will do that, as soon as I get the rest to work.
Fyi currently i've hardly noticed any lag creating 468 Fields and filling them with one or two unicode Lines (Win/Android)

[FourthWorld]

IIRC, IDs are 32-bit unsigned integers, so the range of possible values goes up to about 4 billion.

If you never manually set IDs, since the engine begins with ID 101 and increments within a stack from there with each object created, for all practical purposes over the life cycle of an app there's little risk of running out of IDs.

If you're curious about what happens when you exceed the range of possible values, you can set a control's ID to the highest value allowed (UINT4, or 4294967295), and then create some new controls. Last time I did that (several versions ago) I found nothing amiss during the current session, but after saving the stack I was unable to open it again.

As long as you work with ID ranges well below the maximum, you should have no problem for many years even with the DataGrid or other controls that create large numbers of objects dynamically. Given practical memory limits, ID range could only be a problem if you go out of your way to set IDs to unnecessarily large numbers.

If by chance you happen to have the first project in this community's history that actually runs out of IDs, the worse thing that would be needed would be to simply copy the controls to a new stack (could easily be automated), in which the ID numbers would be reset starting at 101.

[jacque]

Another thing to note is that if you are going to build the stack into an app, which can't save changes to itself, then every time the user opens the app the IDs will be the same numbers as when it was compiled. In other words, during usage they will increase, but on relaunch they'll pick up at the beginning again.

[dunbarx]

Jacque.

But normally the executable would never be the "app", right? So would a stack attached to the file keep its ID's? I would think so, no?

Craig

[jacque]

Jacque.

But normally the executable would never be the "app", right? So would a stack attached to the file keep its ID's? I would think so, no?

Craig

Sorry, I don't know what you mean. If the stack in question is built into a standalone then it will revert its IDs on every launch. If the stack in question is a substack of the mainstack that becomes the standalone, then that too will revert because it's part of the same executable. If the app is created from some other stack, which then opens an unattached document stack, then the document stack will also revert its IDs unless a script specifically saves it to disk.

[FourthWorld]

But normally the executable would never be the "app", right?

Ah, but what is "normal" in the diverse world of LiveCode?

Many times my apps will be self-contained standalones, in which data is stored externally but all UI elements are within the executable standalone.

Other times I'll have the UI stored separately from the standalone, but even then I rarely modify those UI stacks between versions, so any user data remains external to the UI objects.

It's very, very rare in my own work that I ever store user data in stacks the user works with directly. I used to do that more often, but when an app reaches 2.0 and it's time to make big changes to the UI, I found it cumbersome to have to write exporter/importer stuff to migrate data into the new UI, so these days I tend to keep data external so any UI changes happen without any additional effort needed by the user.

That said, there are *many* different ways to architect things in LC, so what's "normal" for me may not be what's "normal" for someone else.

[Havanna]

thx a lot,
that's quite a relief.

If by chance you happen to have the first project in this community's history that actually runs out of IDs, the worse thing that would be needed would be to simply copy the controls to a new stack (could easily be automated), in which the ID numbers would be reset starting at 101.

xcept for datagrid, they don't appear to like being copied.

[FourthWorld]

What issues have you encountered copying DataGrids? As long as you move the template substack along with it that's normally fine.

[dunbarx]

OK. I need to learn this.

I have made standalones, even sold one. I realize I have never needed to reference any control by ID, only by name, and I never created or deleted a control. I always use the "splash stack" method, attaching the "working" stack to the stack file, and opening the splash stack directly, which I always called the "executable". All changes occur in the "working" stack. I may be wrong in all my nomenclature.

So if the attached (working) stack in the standalone creates a new control, then that control may not maintain its ID between sessions? Why is that property different than its number or name?

Craig