A behavior is a script (contained in a button somewhere) that handles certain messages sent to a control. Many controls can use the same behavior, lending consistency to the interface and maintaining only one script to handle the selected messages for all the controls.

Using the example from How to Assign a Behavior, the Search field shown above (2) has its behavior set to the Placeholder Text Behavior (1) button. Here's what normally happens when a mouseUp message is sent to this control (field) by the engine:

1. The mouseUp arrives to be handled by the control script.
2. But the control has no mouseUp handler, so the message passes on to the behavior script.
3. The behavior script handles the mouseUp, and the action stops.

Suppose, however, for this particular control, we want a slightly different behavior, but we don't want to give up all the processing that occurs in the behavior script.

There are two ways we can override or extend the behavior action without changing the behavior itself:

1. We can do some processing before the behavior processing happens.
2. We can do some processing after the behavior processing happens.

How do we manage that? Trevor DeVore invented the simple method described in the next section.

We begin with the normal behavior script (the script of button Placeholder Text Behavior). To allow for overrides, we place the behavior's action in its own MouseUpBehavior handler.

To override this behavior, we have to catch the mouseUp and handle it in the control (field) script, using a MouseUpBehavior message to include the behavior. Here's the control script that allows both kinds of overrides:

That's all there is to it. If only pre-processing is needed, comment out the MouseUpPostProcess call; if only post-processing is needed, comment out the MouseUpPreProcess call.

NOTE: You may be wondering why all the "MouseUp" prefixes. A behavior script might handle many different messages (e.g., mouseEnter, mouseLeave, mouseDown, etc.) and each needs its own override.