Ugly ID memories

[Richard Gaskin]

viktoras didziulis wrote:

> Richard Gaskin wrote:
>> Any problems using the altID property?
>>
>> Since IDs increment for each object created, if restoring an
>> object setting the altID should avoid any conflict with
>> existing or new objects.
>
> Is there anything what can be done with ID that can't be done with
> altID? If not, then simply forgetting about existence of ID and
> using altID in all cases where we are used to refer to ID should
> solve the ID problem completely...

For those who simply want an arbitrary integer they can control that
would certainly do it.

But what differentiates the altID from just using a custom property is
that the altID is checked when addressing objects by ID.  Strange but
true, and very powerful, created to facilitate porting projects from
other xTalks.

When referrring to an object by ID, the built-in IDs are checked first,
and if no match is found then the altIDs are checked. Objects are
checked in layer order.

So if you have a button whose ID is 1003, and an altID of 4444, asking
for either:

   btn id 1003

...or:

   btn id 4444

...will return the same control.

As you can guess, this isn't entirely foolproof, because if you have a
button with an actual ID of 4444 that one will be returned instead.

But IDs for all objects use a single incrementer within a given stack,
and the last ID used is stored in the stack's ID property (which
otherwise has no useful purpose, since it changes whenever a new control
is added, and stacks are required to have unique names anyway).

This is why the altID can be useful for restoring objects:  the
incrementer never works backward, so if you set the altID of a control
to its actual ID prior to turning it into XML or some other
representation, when you recreate it in the same stack you can be
assured no other control is using that ID.

--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com