EDOBE XDOM TAKE 6 IR - PRODUCTSHEET Spezifikationen PDF herunterladen (Seite 84)

CHAPTER 4: User-Interface Tools Defining behavior with event callbacks and listeners 84

The ScriptUI implementation of W3C mouse events follows the W3C DOM level 3 functional specification

(http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-eventgroupings-mouseevents

), with

these differences:

X To create a MouseEvent instance, call ScriptUI.events.createEvent('MouseEvent'), rather than

DocumentEvent.createEvent('MouseEvent').

X The getModifierState method of the MouseEvent interface is not supported.

The ScriptUI implementation of W3C keyboard events follows the W3C DOM level 3 functional

specification {http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-KeyboardEvent

How registered event-handlers are called

When an event occurs in a target, all handlers that have been registered for that event and target are

called. Multiple event handlers can be registered for the same event in different targets, even in targets of

the same type. For example, if there is a dialog with two checkboxes, you might want to register a

click

handler for each

checkbox object. You would do this, for example, if each checkbox reacts differently to

the click.

You can also register events for child objects with a parent object. If both checkboxes should react the

same way to a mouse click, they require the same handler. In this case, you can register the handler with

the parent window or container instead. When the

click event occurs in either child control, the handler

registered for the parent window is called.

You can combine these two techniques, so that more than one action occurs in response to the event. That

is, you can register a general event handler with the parent, and register a different, more specific handler

for the same event with the child object that is the actual target.

The rules for how multiple event handlers are called depend on three phases of event propagation, as

follows:

X Capture phase — When an event occurs in an object hierarchy, it is captured by the topmost ancestor

object at which a handler is registered (the window, for example). If no handler is registered for the

topmost ancestor, ScriptUI looks for a handler for the next ancestor (the dialog, for example), on down

through the hierarchy to the direct parent of actual target. When ScriptUI finds a handler registered for

any ancestor of the target, it executes that handler then proceeds to the next phase.

X At-target phase — ScriptUI calls any handlers that are registered with the actual target object.

X Bubble phase — The event bubbles back out through the hierarchy; ScriptUI again looks for handlers

registered for the event with ancestor objects, starting with the immediate parent, and working back

up the hierarchy to the topmost ancestor. When ScriptUI finds a handler, it executes it and the event

propagation is complete.

For example, suppose a dialog window contains a group which contains a button. A script registers an

event handler function for the

click event at the Window object, another handler at the group object, and

a third handler at the

button object (the actual target).

When the user clicks the button, the

Window object’s handler is called first (during the capture phase), then

the

button object’s handler (during the at-target phase). Finally, ScriptUI calls the handler registered with

the

group object (during the bubble phase).

If you register a handler at an ancestor object of the actual event target, you can specify the third

argument to addEventListener()

, so that the ancestor’s handler responds only in the capture phase, not in

1 2 ... 79 80 81 82 83 84 85 86 87 88 89 ... 303 304

EDOBE XDOM TAKE 6 IR - PRODUCTSHEET Spezifikationen Seite 84

Kommentare zu diesen Handbüchern