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