How/When are behavior references resolved?
Shao Sean
shaosean at wehostmacs.com
Sat Jul 16 08:42:16 EDT 2011
This was the information given when behaviors (aka parentScripts) were
introduced in 4.0, not certain how much has changed in later releases
as I have not upgraded.. You might want to see if they ever did get
around to adding the "resolutionError" message and see if it is
getting fired (which will help you track down the issue)..
PARENT SCRIPTS - RESOLUTION
A control's parent script reference is saved in the stackfile as three
pieces of information:
1) button id
2) stack name
3) mainstack name (if stack is substack)
This is the minimum required information to uniquely identify a button
within a running Revolution environment.
Immediately after loading a stack file, an attempt is made to resolve
all parentScript references - the engine acts as if it constructs a
control reference:
button id <id> of stack <stack name> [ of stack <mainstack name> ]
And attempts to access it. Thus, the stackFiles property will be
searched as appropriate and any needed stacks will be loaded.
At present, if a parentScript fails to resolve it fails silently. In
the next dp, the engine will send a 'resolutionError' message in a
similar way to how it sends a 'scriptError' message when a loaded
stack's script fails to compile. Once resolution has failed for a
parentScript reference, no attempt will be made to resolve it again
*unless* the parentScript of an object is set to the same reference.
A parentScript reference does *not* track changes to the name of the
stack and/or substack - if the names of stacks change that contain
objects being used as parentScripts then all parentScript references
to those objects will be broken.
This apparant strictness of parentScript resolution is necessary to
ensure that references remain consistent throughout a Revolution
session.
More information about the use-livecode
mailing list