Behavior

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:

Datei:Behavior2-0.png
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:

1. The engine looks at the behavior script of the target object - If a before mouseDown handler is present, it executes it.
2. The engine next looks at the object script - If an on mouseDown handler is present, it executes it.
3. The engine now looks at the behavior script - If an after mouseDown handler is present, it executes it.
4. 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),