A WinForms interactor is much like an ordinary WinForms control, but there are a few important differences that are worth pointing out. These are partly motivated by techniques employed in WPF, and partly by the desire to keep things as simple as possible. Note that WinForms (and WPF) supports two approaches for defining the behavior of a control.

• One approach promotes subclassing of forms and controls, and overriding methods like OnPaint and OnMouseDown (we will call these methods event processors, to avoid confusion with the term event handlers).
• In addition to this, WinForms promotes subscribing to events of child controls. In some cases, this allows one to avoid further processing by the child, e.g. by setting a Handled property of the event. Or, one may decide to change some properties of the child just before it processes the event.

WinForms interactors basically offers these approaches too, but its eventing mechanism is somewhat different, and resembles that of tunneled events in WPF. What does this mean?

• Just like WinForms controls, Interactors also have methods like OnPaint and OnMouseDown, but these do notraise any event. Instead, they are considered to just process an event. This means that the base class does not need to be invoked in order to have an event raised. In fact, one can actually avoid invoking the base method in order to avoid particular behavior introduced by the base. It is possible for example, to avoid calling base.OnPaint(...) and thus avoid painting the base presentation, without introducing the side effect of not raising the paint event.
• In order to control interactors "from the outside", it is possible to subscribe to preview events. These events follow the visual tree, and have been named after the corresponding feature in WPF. Preview events get fired for the topmost (visual) element first, then for the child for which the event is relevant, and so forth, until the the bottom of the tree has been reached. At that point the event processor of the bottom element (OnMouseDown etc.) gets invoked.

The latter implies that by default, the most specific (= leaf) interactor determines how to deal with the event. This is a very common situation, as this element is rendered on top of all others. So, if a users clicks on the element she sees (a button for example), that is where the event goes by default. And, if one needs to change the event handling for that element, one just needs to override the appropriate On... event processor.

Preview events allow one to change where events go by default. Preview events have a Cancel property. When set, the event will not be handled by the interactor that raised the preview event, nor by any of its children. Instead, the parent event processor (OnMouseDown etc.) will be invoked. Note that setting the cancel flag cancels that particular instance of the event and events that "follow" it. It does not cancel events that have already been fired. So, if an event needs to be cancelled entirely, this will have to be done at the top level of the visual tree.

Preview events also allow manipulation of the event data, as well as manipulation of the corresponding interactor before it processes the event. The sender of the event identifies interactor that has raised the event. It is probably best to avoid this type of "external" interactor manipulation as much as possible, so that one can determine what happens by looking at the processing method of the interactor alone. There may be cases however that this is less practical.

Some final remarks about the differences between PDFControls and WinForm/WPF:

• Even for tunneled events, WPF always specifies a "source" for the event, which still implies that the event has been generated by a control. In PDFControls this is not the case. Events just "happen" as a result of user input, or other triggers. In case of a mouse event, the event has a location, but it is not yet known which interactor is going to handle it, so it does not have a "source" right from the start. Having a "source" that identifies the most specific UI element over which the event happened is completely irrelevant if that event gets cancelled, and thus never reaches the "source".
• PDFControls has no "bubbled" events, like WinForms and WPF. In fact, bubbled events are a needless concept as soon as tunneled events exist. Please note that if one does have a need for them, it is easy to create an interactor subclass or an interactor layer that does introduce such events.