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

Heriberto Torrado htorrado at
Fri Jun 26 17:59:22 EDT 2020

Thank you very much Richard.

4 Billions is a lot, but I think it could be possible to reach it using 
some kind of automation tool.  I'm thinking about a stock exchange app 
or something that uses many changes and/or math calculations and it is 
displayed on a real time on a created field at runtime.
But it could be the same if for example, we use a long int 32bits data 
type in C language on a 32 bits system and we don't take care.

Nothing to be worried about for the 99.9% of Livecode users.


On 6/26/20 5:21 PM, Richard Gaskin via use-livecode wrote:
> Heriberto Torrado wrote:
> > I read this thread, but it's old and it is not very clear to me.
> >
> >
> >
> > I have the same problem than "Havanna".
> >
> > About six years ago I developed a Livecode desktop app for my company.
> > Several employees open and close the app several times a day.
> > Many fields are created at runtime.
> >
> > The current IDs are in the 250.000
> >
> > Is there a limit?
> > Can we have a problem on the next years?
> > Did it changed with Livecode 64bits versions?
> My understanding is that the 64-bit versions of LC are compatible with 
> 64-bit OSes, but internal addressing is still 32-bit.
> So AFAIK my comment from the thread you linked to still applies:
>    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.


Best regards/ Saludos cordiales/ Cordialement

Heriberto Torrado
​Chief Technology Officer (CTO)
​Director de informática
Directeur informatique

*NetDreams S.C.*

  Address / Dirección / Adresse:​

*USA: *538 East 85th Street, #1C Manhattan NY, NY 10028 USA
*Europe / Europa: *Paseo de la Castellana 135 10ª Planta Madrid 28024 
Spain / España

*Tel - Phone - Fax:*

Phone / Tel USA : +1 917 287 5644 / +1 646 596 8787
Phone / Tel Spain :+34 627 556 500 / + 34 91 063 74 48

    Please consider the environment before printing this email / Por 
favor considera tu responsabilidad medioambiental antes de imprimir esta 

Confidentiality: The information contained in this message as well as 
the attached file(s) is confidential/privileged and is only intended for 
the person(s) to whom it is addressed. If the reader of this message is 
not the intended recipient or the employee or agent responsible for 
delivering the message to the intended recipient, or you have received 
this comunication in error, please be aware that any dissemination, 
distribution or duplication is strictly prohibited, and can be illegal, 
and please notify us immediately and return the original message to us 
at the address above. Thank you.

Confidencialidad: La información contenida en este mensaje y/o 
archivo(s) adjunto(s) es confidencial/privilegiada y está destinada a 
ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Si usted 
lee este mensaje y no es el destinatario señalado, el empleado o el 
agente responsable de entregar el mensaje al destinatario, o ha recibido 
esta comunicación por error, le informamos que está totalmente 
prohibida, y puede ser ilegal, cualquier divulgación, distribución o 
reproducción de esta comunicación, y le rogamos que nos lo notifique 
inmediatamente y nos devuelva el mensaje original a la dirección arriba 
mencionada. Gracias.

Viruses: Although we have taken steps to insure that this e-mail and 
attachments are free from any virus, we advise that in keeping with good 
computing practice, the recipient should ensure they are actually virus 

Virus: Aunque hemos tomado las medidas para asegurarnos que este correo 
electrónico y sus ficheros adjuntos están libres de virus, le 
recomendamos que a efectos de mantener buenas prácticas de seguridad, el 
receptor debe asegurarse que este correo y sus ficheros adjuntos están 
libres de virus.

More information about the use-livecode mailing list