In addition to the various types of methods, you can define events as members of a class. A class event can cause one or more specified methods or internal procedures to execute when the defining class publishes the event in response to a run-time condition that some method of the class identifies. These methods and internal procedures are referred to as event handlers. Any consumer of the class that defines a class event can add (subscribe) or remove (unsubscribe) such handlers for the event.

As with other members of a class, 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 using the built-in Subscribe( ) event method and to unsubscribe event handlers from it using the built-in Unsubscribe( ) event method. Within the defining class, you can also subscribe and unsubscribe handlers for a event, but you can publish a class event using the built-in Publish( ) event method only from within the class where it is defined and implemented, regardless of its access mode.

You can subscribe an event handler to a private event from within the class that defines the event. An instance can also subscribe an event handler to a private event of another instance if both instances are from the same class. You can subscribe an event handler to a protected event from within the class that defines the event and from within any class that inherits the defining class. An instance can subscribe an event handler to a protected event from a second instance that is at the same level or in a super class in the class hierarchy. You can subscribe to public events both from within the class hierarchy and from outside the class hierarchy where they are defined.

The class that defines an event controls how and when the event is published. However, an application that consumes this class can subscribe or unsubscribe event handlers to the event from anywhere in the application that the event access mode allows. In addition, because you can both subscribe and unsubscribe event handlers, you can have different handlers registered to execute for the same event when it is published at different times. Thus, you can dynamically change application behavior in response published class events.

A class event also has a signature defined for it with zero or more method parameters. Any event handler subscribed to a class event must have a signature that is compatible with the method signature defined for the event.

In addition to the various types of methods and events of a class, you can also define triggers (ON statements) that specify behavior (handler code) for handle-based object events on widgets that you define in a class. Triggers defined in a class are privately scoped to the class and handle events only for widgets activated by methods of the defining class. These triggers thus support the behavior of these class methods. Like static widgets, streams, and work tables, triggers that are part of a class definition are not class members that can be inherited by a subclass, nor can they be affected by an APPLY statement executed in another class definition.