Image IDs

J. Landman Gay jacque at hyperactivesw.com
Mon Apr 27 16:14:29 EDT 2015


On 4/27/2015 12:56 PM, Peter Haworth wrote:
> My fist confusion comes from the dictionary entry for the ID property.  It
> lists ranges of image IDs that are reserved for specific purposes.  The
> range 200,000-299,999 is described as "reserved for application use" What
> does that mean exactly?  For example, if I create a new image in a stack,
> LC allocates it an id in the 1000 range upwards, not in the 200,000-299,999
> range.  Should I be changing the ID to be in the "reserved for application
> use" range?

The lower IDs are historical, and the behavior hasn't changed since 
MetaCard. But when LC took over the engine they assigned blocks of IDs 
to avoid the conflicts that can occur. It doesn't always work, because 
people tend to leave the IDs at their default assignments. When I create 
apps that will be self-contained I don't bother to change ID numbers, 
but if I'm creating tools for other people's use I do. If you remember 
to change the first new object ID during development, all subsequent 
objects will increment by 1 from there, so if you think ahead you can 
change only one ID and all your other controls will be in range.

"Reserved for application use" means the range is reserved for your own 
apps or stacks, and the IDE will never assign numbers in that range.

For the rest of it, my interpretation is:

> 1) The stack of the object's behavior (if applicable)

Clear enough, I think. If a behavior is assigned, the engine first looks 
at the stack containing the behavior button.

> 2) The stack of the owner of the object's behavior (if applicable)
>  ...

If the behavior button is in a substack, it's owner is the mainstack, so 
it looks at that mainstack next. This may or may not be the original 
object's mainstack because behaviors can be stored in other unrelated 
stacks. I think the elipsis is because behaviors can be chained, so the 
engine will follow the chain, looking in every stack that contains a 
behavior in the chain.

> n) The stack of the object's stack's behavior (if applicable)

If the stack where the object lives has a behavior assigned, it looks in 
the stack containing that behavior.

> A) The object's stack

Now that behaviors are out of the way, it looks in the original 
objects's stack.

> B) The object's stack's mainstack (if a substack)
> C) The object's stack's mainstacks substacks
> D) The list of open stacks, in order they were loaded

A-D follows the original search path before behaviors were implemented, 
and traces the stack hierarchy from substack to mainstack. (C) is 
missing an apostrophe, it should be "the object's stack's mainstack's 
substacks." Or better, "the other substacks of the object's mainstack." 
I.e., it searches all the other substacks in the stackfile. If the image 
still isn't found, it moves on to other separate open stacks.

And yes, this could use a rewrite. It reads like some engineer wrote it 
while looking at the code. :)


-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com




More information about the use-livecode mailing list