Get Example source ABAP code based on a different SAP table
• FOR EVENT OF METHODS
METHODS>, FOR EVENT> Short Reference >
ABAP_SYNTAX METHODS meth $[ABSTRACT$|FINAL>$] $|$[DEFAULT IGNORE$|FAIL>$]> FOR EVENT evt OF ${class$|intf$}> $[IMPORTING p1 p2 ... $[sender$]$].>
ABAP Addition ... IMPORTING p1 p2 ... $[sender$]>
What does it do? This statement declares the instance method meth> as an event handler> for the event evt> of the class class> or interface intf>. For class> and intf>, all classes and interfaces can be specified that are visible in this position and that contain an event evt> as a component that is visible here. The visibility section of the event handler cannot be more general than the visibility section of the event because otherwise properties of the method would be defined in a visibility section more restricted than the method itself. If the event evt> is an instance event, the event handler meth > can handle it for all objects whose classes match class> or that are subclasses of class> or which implement the interface intf> directly or by using a superclass. If the event is a static event>, the event handler meth > can handle it for the class class> and its subclasses or for all classes that implement the interface intf>.
Using the additions ABSTRACT>> and FINAL>>, event handlers can either be made abstract or final just like general methods> in classes.
The addition DEFAULT>> can be used to make event handlers optional, just like general methods> in interfaces.
Latest notes:
To ensure that an event handler handles a raised event, it must be registered with the statement SET HANDLER> >. In event handlers, no class-based exceptions can be declared using RAISING>. See Class-Based Exceptions in Event Handlers>.
When declaring event handlers for static events, note that these events are generally raised in static methods as well. In such a method, the class in which the method is declared is always the raising class, and not the subclass in which or with whose name the method was called.
Method declarations using this syntax are not to be confused with method declarations in the context of RAP business events >: METHODS, FOR ENTITY EVENT> > NON_V5_HINTS ABAP_HINT_END • sender METHODS
ABAP Addition
What does it do? The addition IMPORTING> defines the input parameters of the event handler. For p>, only those names of formal parameters can be specified that are defined as output parameters of the event by using the addition EXPORTING> of the statement EVENTS>> or CLASS-EVENTS>> in the declaration of the event evt> in the class class> or in the interface intf>. The additions TYPE> or LIKE> and OPTIONAL> or DEFAULT> are not possible. The typing> of the input parameters and whether they are optional, and any replacement parameters, are inherited from the declaration of the event. Not all output parameters of the event need to be specified. If evt> is an instance event, a formal parameter called sender > can be defined as an input parameter of an event handler in addition to the explicitly defined output parameters of the event. The formal parameter sender> is an implicit output parameter of every instance event. It is completely typed as a reference variable, which itself has the class class> or the interface intf> as a static type, as specified in the declaration of the event handler after EVENT evt OF>. If the event handler is called by an instance event, it is passed a reference to the raising object in sender>.
Latest notes: Each event handler determines the type of its formal parameter sender>. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 The class picture> contains an event handler handle_double_click> for the instance event picture_dblclick > of the global class cl_gui_picture>. The event handler inherits two explicit output parameters of the event and the implicit parameter sender> as input parameters. ABEXA 00417 ABAP_EXAMPLE_END