Allows an object to inherit its script handlers from another object. Syntax:
set the behavior of <object> to [<button> | <stack>]
Examples:
set the behavior of tNewGroup to the long id of button "Widget" of card "Behaviors"
Behaviors are a method to create common functionality between objects without duplicating the scripts.
The behavior property does not track changes to the name of the stack and/or substack - if the name of a stack containing behavior objects is changed, then all references to these behaviors will be broken. This apparent strictness is necessary to ensure that behaviors act consistently while LiveCode is running.
The value of the behavior property is a reference to a button or stack containing the script to use. The format stored in the object it's assigned to is similar to a long ID. The main difference is that where a long ID includes the full path to the stack file, the form stored in the behavior includes only the stack name, allowing the reference to continue to work after the stack file has been moved to another computer. If you set the behavior to a long ID, LiveCode converts it to a rugged form without the stack file path.
By default, the behavior of newly created objects is empty.
An object with a behavior set will act as though its script was set to the script of the behavior button or stack. If multiple objects share the same behavior, each will have its own set of script local variables. Any references to me, the owner of me, and so on, will resolve to the child object currently executing.
The button or stack containing the behavior script can be located anywhere. In particular this allows for it be located in a password protected stack, allowing you to protect the script without need to protect the controls using it.
Behaviors are resolved by LiveCode immediately after loading a stack file. The engine acts as though it is resolving a control reference of the form:
button id <id> of stack <stack name> [ of stack <mainstack name> ]
Thus the stackFiles property will be searched and stacks loaded into
memory as appropriate.
The behavior property does not track changes to the name of the stack and/or substack - if the name of a stack containing behavior objects is changed, then all references to these behaviors will be broken. This apparent strictness is necessary to ensure that behaviors act consistently while LiveCode is running.
You can chain behaviours, so you can assign to object A the behaviour the behavior of object B, and objec B has the behavior of object C. Any message trapped by the last behavior can passed (see pass) to the object script of the precedent object. This way you can modularize you code. In the following example, just click on button 1 and the field will change its content from 1 to 43:
The synonym parentScript is deprecated and should not be used.
Changes: From version 6.7.5, a stack can be used as a behavior. From version 6.1, the behavior property of a control currently being used as a behavior will now be taken into account and result in the child behavior deferring to the parent behavior in the same way a control defers to its behavior.
Before[]
Before is a new control structure for behaviors, example:
before mouseUp answer "before mouse up received" end resizeStack
The before handler is exclusive to behavior scripts and is sent to a behavior script before all messages. For example, consider a mouseDown message moving through the message path. It gets to an object with a behavior script:
- The engine looks at the behavior script of the target object - If a before mouseDown handler is present, it executes it.
- The engine next looks at the object script - If an on mouseDown handler is present, it executes it.
- The engine now looks at the behavior script - If an after mouseDown handler is present, it executes it.
- The engine finally looks at the object script - If a pass mouseDown or no mouseDown handler is present, it moves on to the parent object.
A before handler allows developers to produce behavior scripts which can handle messages sent to a control without having any effect on the message path, unlike front and back scripts.
See also: button (object), field (object), stack (object), ID (property), name (property), password (property), stackFiles (property),