Class events, along with associated internal procedures and class methods that are subscribed as handlers for these events, contribute to defining the behavior of a class. A class event allows a class to provide notification of a particular condition by publishing the event when the condition is identified. Publishing the event then causes one or more event handlers that are subscribed to the event to execute. These event handlers can include any compatible method or internal procedure. Each time the event is published, the currently subscribed event handlers execute one after the other, and in no guaranteed order. After the final event handler completes, execution returns to the next statement after the statement that published the event.
A class event is a class member that you must define like any data member, property, or method. Thus, a class event can be inherited by any derived class, depending on its access mode (PRIVATE, PROTECTED, or PUBLIC). However, access to a class event outside of the class where it is defined only allows you to subscribe event handlers to it. You can publish a class event only from within the class where it is defined and implemented, regardless of its access mode.
When you define a class event, you also define a method signature (which is always
VOID) for any event handlers that you subscribe to the event. For methods that you subscribe to, ABL type checks this event signature at compile time, like any method signature. However, for internal procedures that you subscribe, the AVM checks signature compatibility only at run time. Note that you pass the parameters for an event when you publish it, and the data flow through these parameters depends on the modes of the parameters (
INPUT,
OUTPUT, or
INPUT-OUTPUT) and how many event handlers you have subscribed to the event. The values of
OUTPUT and
INPUT-OUTPUT parameters are determined by the last handler to run. In the case of
INPUT-OUTPUT parameters, each handler invoked for the published event has access to the value set by the previous handler. For more information on how data flows through the signatures of published class events, see
Publishingclass events.
By default, a class event is an instance member that is defined for access, according to its access mode, only within or through the instance of the class in which it is defined. A class event can also be defined as static, which associates the event with the class type (not an instance) and makes it available, according to its access mode, throughout the ABL session without the need for a class instance. For more information on accessing static events, see
Accessingstatic members.
You can also define an abstract event prototype in an abstract class type definition, and you can define an interface event prototype in an interface type definition. An event prototype defines an event without an implementation that cannot be published. The syntax for an event prototype is largely identical to the syntax of the implemented event. However, the effect of implementing an event prototype defines the event in a class where it can be published to the application. Both types of event prototype (abstract and interface) must be implemented appropriately in the class hierarchy where they are defined. For more information on defining abstract event prototypes, see the syntax description in this section. For more information on defining interface event prototypes, see
Defininginterfaces and
Usingthe INTERFACE construct.
ABL provides three built-in event methods (
Publish( ),
Subscribe( ), and
Unsubscribe( )) to publish and manage event handler subscriptions for a class event. For more information on publishing and subscribing to class events, see
Publishing and subscribing to class events.
