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 | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
