Documente Academic
Documente Profesional
Documente Cultură
ABAP® Objects
Reference
A comprehensive guide to all
ABAP-language elements
in two volumes
Volume I & II
abapEAL.fm Seite 5 Freitag, 31. Januar 2003 12:51 12
Contents at a Glance
Volume I
Part 1 Syntax 29
Volume II
Contents
Preface 17
Part 1 Syntax 29
2 ABAP Syntax 31
2.1 ABAP Statements 31
2.2 ABAP Language Elements 31
2.2.1 Operators 32
2.2.2 Operands 33
2.2.3 Designations for Operands 33
2.2.4 Specifying Operands Statically or Dynamically 39
2.2.5 Data Objects in Operand Positions 40
2.3 Naming Conventions 43
2.4 Chained Statements 44
2.5 Comments 45
3 Introductory Statements 49
3.1 Overview 49
3.2 Executable Programs 50
3.2.1 Additions for the Basic List of the Program 51
3.2.2 Addition for the Message Class 52
3.2.3 Addition for Defining a Logical Database 53
Contents 7
abapIVZ.fm Seite 8 Freitag, 31. Januar 2003 12:51 12
4 Modularization Statements 57
4.1 Overview 57
4.2 Procedures 58
4.2.1 Methods 58
4.2.2 Function Modules 59
4.2.3 Subroutines 60
4.3 Dialog Modules 65
4.4 Event Blocks 66
4.4.1 Program Constructor 66
4.4.2 Reporting Events 67
4.4.3 Selection Screen Events 72
4.4.4 List Events 78
4.5 Source Text Modularization 84
4.5.1 Include Programs 84
4.5.2 Macros 85
8 Contents
abapIVZ.fm Seite 9 Freitag, 31. Januar 2003 12:51 12
Contents 9
abapIVZ.fm Seite 10 Freitag, 31. Januar 2003 12:51 12
8 Typing 187
8.1 Overview 187
8.2 Syntax of Typing 187
8.2.1 Generic Typing 188
8.2.2 Complete Typing 189
8.3 Checking the Typing 190
8.3.1 General Rules 190
8.3.2 Literals as Actual Parameters 190
10 Contents
abapIVZ.fm Seite 11 Freitag, 31. Januar 2003 12:51 12
Contents 11
abapIVZ.fm Seite 12 Freitag, 31. Januar 2003 12:51 12
12 Contents
abapIVZ.fm Seite 13 Freitag, 31. Januar 2003 12:51 12
Contents 13
abapIVZ.fm Seite 14 Freitag, 31. Januar 2003 12:51 12
14 Contents
abapIVZ.fm Seite 15 Freitag, 31. Januar 2003 12:51 12
Contents 15
abapIVZ.fm Seite 16 Freitag, 31. Januar 2003 12:51 12
16 Contents
abapIV2.fm Seite 491 Freitag, 31. Januar 2003 12:56 12
Contents
25 Dynpros 505
25.1 Overview 505
25.2 Flow Logic Statements 506
25.2.1 Flow Logic Event Blocks 508
25.2.2 Calling Dialog Modules 509
25.2.3 Controlling Data Transfer 511
25.2.4 Processing Chains 514
25.2.5 Table Controls 516
25.2.6 Calling a Subscreen 519
25.3 ABAP Statements for Dynpros 522
25.3.1 Calling Dynpro Sequences 523
25.3.2 Setting the Next Dynpro 524
25.3.3 Setting the GUI Status 524
25.3.4 Determining the GUI Status 526
25.3.5 Setting the GUI Title 528
25.3.6 Determining Attributes of Dynpro Fields 529
25.3.7 Modifying Attributes of Dynpro Fields 531
25.3.8 Setting the Cursor 532
25.3.9 Determining the Cursor Position 535
25.3.10 Declaring a Control 537
25.3.11 Initializing a Control 543
25.3.12 Exiting the Step Loop 543
25.3.13 Holding Field Contents 544
25.3.14 Suppressing the Display 545
25.3.15 Leaving a Dynpro 545
Contents 491
abapIV2.fm Seite 492 Freitag, 31. Januar 2003 12:56 12
27 Lists 605
27.1 Overview 605
27.1.1 Lists as Screens 605
27.1.2 Lists in the ABAP Program 605
27.1.3 Basic List 605
27.1.4 Details Lists 605
27.1.5 The Structure of a List 606
27.1.6 Print Lists 607
27.1.7 Lists and ABAP Objects 607
27.1.8 Lists and Unicode 607
27.1.9 Statements for List Processing 608
27.2 Creating Lists 609
27.2.1 Writing Data in Lists 609
27.2.2 Creating Horizontal Lines 634
27.2.3 Formatting Lists Section by Section 635
27.2.4 Displaying Blank Lines 642
27.2.5 Vertical Positioning of the List Cursor 643
27.2.6 Horizontal Positioning of the List Cursor 648
27.2.7 Fixed Areas When Scrolling Horizontally 649
27.2.8 Page Breaks and Print Lists 650
27.2.9 Conditional Page Breaks 658
27.2.10 Saving Variables with List Lines 659
27.2.11 Print List Page Margins 661
27.2.12 Controlling Print Lists 661
27.3 Processing Lists in the List Buffer 665
27.3.1 Reading List Lines 665
27.3.2 Modifying List Lines 668
492 Contents
abapIV2.fm Seite 493 Freitag, 31. Januar 2003 12:56 12
28 Messages 689
28.1 Overview 689
28.1.1 Storing Messages 689
28.1.2 Message Types 689
28.2 Sending Messages 692
28.2.1 Variant 1 692
28.2.2 Variant 2 693
28.2.3 Variant 3 693
28.2.4 Variant 4 694
28.2.5 Addition Options 695
Contents 493
abapIV2.fm Seite 494 Freitag, 31. Januar 2003 12:56 12
494 Contents
abapIV2.fm Seite 495 Freitag, 31. Januar 2003 12:56 12
31.3.4 Treatable Exceptions During the Import from Data Clusters 795
31.4 Reading the Directory of a Data Cluster 795
31.5 Deleting a Data Cluster 797
31.6 Deleting a Data Cluster in the ABAP Memory 798
Contents 495
abapIV2.fm Seite 496 Freitag, 31. Januar 2003 12:56 12
496 Contents
abapIV2.fm Seite 497 Freitag, 31. Januar 2003 12:56 12
Contents 497
abapIV2.fm Seite 498 Freitag, 31. Januar 2003 12:56 12
498 Contents
abapIV2.fm Seite 499 Freitag, 31. Januar 2003 12:56 12
Contents 499
abapIV2.fm Seite 500 Freitag, 31. Januar 2003 12:56 12
500 Contents
abapIV2.fm Seite 501 Freitag, 31. Januar 2003 12:56 12
F Glossary 1037
Index 1079
Contents 501
KAP07.fm Seite 147 Freitag, 31. Januar 2003 2:28 14
7.1 Overview
This chapter describes the definition of classes and interfaces, as well as
their components. Classes and interfaces are the foundation of ABAP
Objects, the object-oriented component of the ABAP language. You can
define classes and interfaces in ABAP programs with the following pro-
gram types (see Table 3.1):
왘 In a class pool, you can use the Class Builder in the ABAP Workbench to
define one global class of the class library. This global class can be used
in all other ABAP programs. You can also define local classes and inter-
faces in a class pool, for use in the class pool itself.
왘 In an interface pool, you can use the Class Builder in the ABAP Work-
bench to define one global interface of the class library. This global
interface can be used in all other ABAP programs. You cannot define
local classes or interfaces in an interface pool.
왘 In all other ABAP programs (except type groups), you can define local
classes and interfaces for use in the program itself.
Statement Section
CLASS 7.2
INTERFACE 7.3
CLASS
Syntax
CLASS class DEFINITION [PUBLIC]
[ INHERITING FROM superclass]
[ ABSTRACT]
[ FINAL]
[ CREATE {PUBLIC|PROTECTED|PRIVATE}]
[[ GLOBAL] FRIENDS [classi] [ifaci]].
[PUBLIC SECTION].
[components]
[PROTECTED SECTION].
[components]
[PRIVATE SECTION].
[components]
ENDCLASS.
You can use the additions of the CLASS statement to publish a class glo-
bally in the class library, define an inheritance relationship, make the class
abstract or final, define whether it can be instantiated, and offer friendship
to other classes and/or interfaces.
This statement defines the public visibility area of class class. All class
components that you declare in the area after the PUBLIC SECTION
statement can be addressed from outside the class, from within its sub-
classes, and within the class itself.
This statement defines the protected visibility area of class class. All
class components that you declare in the area after the PROTECTED SEC-
TION statement can be addressed in the subclasses of the class and within
the class itself.
This statement defines the private visibility area of class class. All class
components that you declare in the area after the PRIVATE SECTION
statement can be addressed only within the class itself.
Syntax
components.
You define the components of the classes in the visibility areas. The fol-
lowing declaration statements are possible for components:
Note
All the components of a class lie within one namespace. The name of a
component must be unique within a class, regardless of its type (data
type, attribute, method, event, or alias name). The components of an
implemented interface differ from the directly declared components of
the class through prefix ifac~ (name of the interface with the interface
component selector).
Syntax
... PUBLIC ...
When you use the addition PUBLIC, the class becomes a global class of
the class library. The addition PUBLIC is possible for only one class of a
class pool and is generated by the Class Builder when you create a global
class. All classes without the addition PUBLIC are local classes of their
program.
Note
You cannot use the TYPES statement to declare separate data types in the
public visibility area of a global class. Moreover, you can use only globally
declared data types there.
Syntax
... INHERITING FROM superclass ...
If you use the addition INHERITING FROM, the class is derived from the
superclass superclass through inheritance, and therefore becomes its
direct subclass. The superclass superclass can be any non-final class that
is visible at this point.
Each class can have only one direct superclass, but can have several direct
subclasses (simple inheritance). Any class without the addition INHERIT-
ING FROM implicitly inherits from the predefined empty class object.
Taken together, all the classes in ABAP Objects form an inheritance tree, in
which a clearly defined path exists from each class to the root node,
object.
Note
The public and protected components of all the classes within a path of
the inheritance tree all lie within the same namespace. New components
in a subclass may not have names that are identical to public or protected
components that were inherited from the superclasses.
Syntax
... ABSTRACT ...
The addition ABSTRACT defines an abstract class, class. You cannot gen-
erate instances of an abstract class. To use the instance components of an
abstract class, you have to instantiate a non-abstract subclass of the class.
Syntax
... FINAL ...
The addition FINAL defines a final class class. You cannot derive sub-
classes of a final class. All methods of a final class are implicitly final, which
means that you cannot explicitly declare them as final.
Note
If a class is both abstract and final, you can use only its static components.
While you can declare instance components, you cannot use them.
Example
In the example below, an abstract class c1 and a final class c2 are defined,
and c2 inherits from c1. c1 is implicitly a subclass of the blank class
object. You can access m1 in c2, but a1.
METHODS m2.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD m1.
WRITE / a1.
ENDMETHOD.
ENDCLASS.
CLASS c2 IMPLEMENTATION.
METHOD m2.
m1( ).
ENDMETHOD.
ENDCLASS.
...
7.2.1.7 Instantiation
Syntax
... CREATE {PUBLIC|PROTECTED|PRIVATE} ...
The addition CREATE defines the context in which class can be instanti-
ated—that is, where the CREATE OBJECT statement can be executed for
that class.
Note
If a class can be instantiated as private, we recommend making it final as
well, as its subclasses cannot be instantiated if they are not friends of the
class.
7.2.1.8 Friends
Syntax
... [GLOBAL] FRIENDS [classi] [ifaci].
The addition FRIENDS makes class class a friend of classes classi and/
or interfaces ifaci. At the same time, all subclasses of classes classi, all
classes that implement one of the interfaces ifaci, and all interfaces that
have one of the interfaces ifaci as a component interface become friends
of class. You have to specify at least one class or interface.
The friends of a class have unrestricted access to the protected and private
components of that class, and can generate unrestricted instances of the
class.
If you do not use the GLOBAL additions, you can specify all classes and
interfaces for classi and ifaci that are visible at this point. If you define
global classes and interfaces in the class library as friends, please note that
in these objects the local classes of other ABAP programs are not visible.
In such cases, static access to the components of class is not possible.
The addition GLOBAL is allowed only when you use the addition PUBLIC—
for the global class of a class pool—at the same time. You can list other
global classes and interfaces from the class library after GLOBAL FRIENDS.
This addition is generated when the Class Builder creates a global class
and you have specified friends at the corresponding tab page of the Class
Builder.
Example
In the example below, class c2 is a friend of interface i1, and therefore
also of the implementing class c1. It can instantiate these objects and
access their private component a1.
INTERFACE i1.
...
ENDINTERFACE.
CLASS c2 DEFINITION.
PUBLIC SECTION.
INTERFACES i1.
METHODS m2.
ENDCLASS.
CLASS c2 IMPLEMENTATION.
METHOD m2.
DATA oref TYPE REF TO c1.
CREATE OBJECT oref.
WRITE oref->a1.
ENDMETHOD.
ENDCLASS.
Syntax
CLASS class DEFINITION LOCAL FRIENDS [classi] [ifaci].
This statement turns the local classes and interfaces of a class pool,
classi and ifaci, into friends of its global class. You have to specify at
least one class or interface.
This section does not introduce a declaration section, and you cannot
complete it with ENDCLASS. You have to specify it in the class pool before
the definition of the local classes and interfaces, classi and ifaci, if you
want them to have access to the private and protected components of the
global class, class.
Syntax
CLASS class IMPLEMENTATION.
...
METHOD ...
...
ENDMETHOD.
...
ENDCLASS.
Note
A class that—in accordance with its declaration section—does not have
to implement any methods has either a blank implementation section or
none at all.
Example
In the following example, three methods of class c2 have to be imple-
mented. Method m1 in c1 is abstract and does not have to be imple-
mented.
INTERFACE i1.
METHODS m1.
ENDINTERFACE.
CLASS c2 IMPLEMENTATION.
METHOD m1.
...
ENDMETHOD.
METHOD m2.
...
ENDMETHOD.
METHOD i1~m1.
...
ENDMETHOD.
ENDCLASS.
Syntax
CLASS class DEFINITION { DEFERRED | LOAD }.
The two variants of the CLASS statement serve to declare a class class in
the program independently of the location of the actual definition. They
do not introduce a declaration section, and you cannot complete them
with ENDCLASS. The additions have the following meanings:
왘 The variant with addition DEFERRED declares a local class before its
actual definition in the program. The program has to have a declaration
section for class later in the program. This statement is required if
you want to refer to a class before it is actually defined. Access to indi-
vidual components is not possible before the actual definition.
왘 The variant with addition LOAD loads a global class from the class
library. This statement is required prior to Release 6.40 if you want to
access one of the static components of class within a program, or if
you want to declare an event handler for class before class is loaded
automatically. All other accesses load class automatically. In Release
6.40 and later, the addition LOAD is required only when the compiling
of an ABAP program fails because it contains recursive accesses to a
global class. In such cases, you may be able to make the program com-
pilable by explicitly loading the class before the recursion.
Example
In the following example, class c1 uses class c2 and vice-versa. As a
result, one of the classes has to be declared before its actual definition. In
addition, global class cl_gui_cfw is loaded explicitly before one of its
static attributes is used.
CLASS c2 DEFINITION.
PUBLIC SECTION.
DATA c1ref TYPE REF TO c1.
ENDCLASS.
CLASS c1 DEFINITION.
PUBLIC SECTION.
DATA c2ref TYPE REF TO c2.
ENDCLASS.
INTERFACE
Syntax
INTERFACE ifac.
[components]
ENDINTERFACE.
Syntax
components
Note
All the components of an interface lie within one namespace. The name
of a component must be unique within an interface, regardless of its type
(data type, attribute, method, event, or alias name). The components of
an integrated interface differ from the directly declared components
through prefix ifac~ (name of the interface with the interface compo-
nent selector).
Example
In the following example, an interface, i1, is declared with three interface
components, a1, m1, and e1. Class c1 implements the interface, which
makes the interface components public components of the class that can
be addressed using the interface component selector (~).
INTERFACE i1.
DATA a1 TYPE string.
METHODS m1.
EVENTS e1 EXPORTING value(p1) TYPE string.
ENDINTERFACE.
CLASS c1 DEFINITION.
PUBLIC SECTION.
INTERFACES i1.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD i1~m1.
RAISE EVENT i1~e1 EXPORTING p1 = i1~a1.
ENDMETHOD.
ENDCLASS.
Syntax
INTERFACE ifac { DEFERRED | LOAD }.
왘 Attributes
왘 Methods
왘 Events
Attributes are the data objects of a class. You can also declare class-spe-
cific data types. You declare attributes and data types with the general
statements TYPE-POOLS, TYPES, DATA, CLASS-DATA, and CONSTANTS,
which—with the exception of CLASS-DATA—can also be used in other
contexts and are described in Chapter 6.
To declare methods and events, you use specific statements that are pos-
sible only in the declaration section of classes and interfaces.
7.4.1 Methods
You use the METHODS and CLASS-METHODS statements to declare meth-
ods. They define how the class responds. You define the interface of a
method in the declaration. Different categories of methods exist for spe-
cific tasks:
왘 General methods
왘 Functional methods
왘 Constructors
왘 Event handlers
METHODS
The most general form of the METHODS statement lets you define instance
methods with any input and output parameters.
Syntax
METHODS meth [ABSTRACT|FINAL]
[IMPORTING {parameteri} [PREFERRED PARAMETER p]]
[EXPORTING {parameteri}]
[CHANGING {parameteri}]
[{RAISING|EXCEPTIONS} {exci}].
The other additions define the parameter interface of the method and
define which exceptions the method can propagate and/or trigger.
Parameter interface
The additions IMPORTING, EXPORTING, and CHANGING define the signa-
ture of method meth:
Syntax of parameteri
... { {VALUE(pi)}|{REFERENCE(pi)}|{pi} {typing}
[OPTIONAL|{DEFAULT defi}] } ...
You have to use the addition typing to type each formal parameter. The
syntax of typing is described in Section 8.2. When you type a formal
parameter, that typing is checked against the data type of any actual
parameter that is passed on (see Section 8.3). The defined type also
determines the operand positions where the formal parameter(s) can be
used in the method.
You can use OPTIONAL or DEFAULT to define input parameters and input/
output parameters as optional parameters; if you use DEFAULT, you can
also specify a default parameter defi. If a parameter is optional, you do
not have to specify an actual parameter when you call the method. If you
use the addition OPTIONAL, the formal parameter is initialized type-spe-
cifically; if you use DEFAULT, it assumes the value of the default parame-
ter, defi. defi can be any data object with a suitable type that is visible
at this point.
Note
If a formal parameter is typed as a reference variable and cannot be
changed in the procedure, the type check is performed as it is for a nar-
rowing cast. If it can be changed in the procedure, the actual parameter
must be compatible with the formal parameter.
Example
Method read_spfli_into_table in the following example has one
input parameter and one output parameter, both of which are completely
typed through references to the ABAP Dictionary.
Class-based exceptions
Syntax
... RAISING {exci} ...
You can use the addition RAISING to pass class-based exceptions, exci,
on to the calling program. The exceptions can be subclasses of CX_
STATIC_CHECK and CX_DYNAMIC_CHECK which are triggered in or
propagated into the method of the ABAP runtime environment or with
the RAISE EXCEPTION statement, but are not handled in a TRY block
(see Section 15.2).
exci can equal any exception classes that are subclasses of the above
superclasses and are visible at this point. You have to enter the exception
classes in the ascending order of their inheritance hierarchy.
Notes
왘 Exceptions that involve the subclasses of CX_STATIC_CHECK and CX_
DYNAMIC_CHECK have to either be handled within the method or
passed on explicitly with the addition RAISING. This is checked during
the syntax check for CX_STATIC_CHECK, and at runtime for CX_
DYNAMIC_CHECK.
왘 You cannot use the CATCH SYSTEM-EXCEPTIONS statement in a
method that propagates class-based exceptions with addition RAIS-
ING. You have to trap these exceptions in a TRY block instead (see
Chapter 15).
Example
In class math below, method divide_1_by propagates all the exceptions
represented by class CX_SY_ARITHMETIC_ERROR and its subclasses. If an
input parameter, operand, is given a 0 value during a call, for example,
...
Note
You cannot use the additions RAISING and EXCEPTIONS at the same
time. We recommend using class-based exceptions for new develop-
ments in Release 6.10 and later, as they are independent of any specific
method.
Example
In class math below, a separate exception arith_error is defined for
method divide_1_by. This exception is triggered with the RAISE state-
ment when an arithmetic error occurs. For example, if an input parame-
ter, operand, is given a 0 value during a call, exception arith_error is
triggered during the internal-method handling of exception CX_SY_
ZERODIVIDE and is handled during the method call.
...
IF sy-subrc = 0.
WRITE result.
ELSE.
WRITE 'Arithmetic error!'.
ENDIF.
Abstract methods
Syntax
... ABSTRACT ...
Note
Although abstract methods can be defined in classes that are both
abstract and final, they cannot be implemented, which means you cannot
use them.
Final methods
Syntax
METHODS ... FINAL ...
The addition FINAL is possible only in classes, not in interfaces. The addi-
tion FINAL defines a final method, meth. A final method cannot be rede-
fined in a subclass. All methods in final classes are automatically final, and
the addition FINAL is not allowed here.
Functional methods can have any number of input parameters, and have
exactly one return value as output parameter.
Syntax
METHODS meth [ABSTRACT|FINAL]
[IMPORTING {parameteri}]
RETURNING VALUE(r) {TYPE type_spec}|{LIKE dobj_spec}
[{RAISING|EXCEPTIONS} {exci}].
As far as the typing of return value r with typing is concerned, the same
rules apply as for the typing of IMPORTING, EXPORTING, and CHANGING
parameters (see Section 8.2), with the exception that a return value
always has to be completely typed: You cannot specify any of the generic
types from Table 5.3 for typing.
Notes
왘 When you use a functional method in an operand position, class-based
exceptions that the method propagates with RAISING can be handled
in a TRY block or propagated further, as with the general methods. In
contrast, the exceptions for a functional method that you define with
EXCEPTIONS cannot be handled in operand positions, and will always
cause a runtime error.
왘 If a functional method has the same name as a built-in function (see
Section 5.4), the expression meth( a ) in an operand position always
calls the functional method. This case can occur only in methods of the
class in the functional method, however.
Example
Functional method factorial in the following example has a return
value, fact, with type i. The COMPUTE statement illustrates the method
call in an operand position.
...
Syntax
METHODS constructor [FINAL]
[IMPORTING {parameteri}]
[{RAISING|EXCEPTIONS} {exci}].
This statement is possible only in the public visibility area of the declara-
tion section of a class. It declares the instance constructor of the class,
constructor.
Each class has a predefined method called constructor in its public vis-
ibility area. You can use the explicit declaration to define the interface of
method constructor class-specifically and to implement its functional-
ity. If you do not declare it explicitly, the instance constructor assumes the
signature from the instance constructor in the direct superclass and calls
it implicitly.
You can use the addition IMPORTING to define input parameters, accord-
ing to the same rules as for the general methods. The additions RAISING
and EXCEPTIONS for propagating and defining exceptions also have the
same meaning as under the general methods.
The instance constructor is called once for each instance of a class, with
the CREATE OBJECT statement, directly after the instance is generated. In
the process, actual parameters must be assigned for all non-optional input
parameters, and exceptions can be handled or passed on. A call using
CALL METHOD is not possible, except in the call of the superclass con-
structor with super->constructor in the redefined constructor of a
subclass.
Instance constructors are implicitly final. You can specify the addition
FINAL, but it is not necessary.
Notes
왘 Instance constructors represent an exception to the rule that all public
components along a path in the inheritance tree have to line in the
same namespace. The instance constructor of each class has a separate
interface and a separate implementation. You cannot redefine an
instance constructor.
왘 Instance constructors are declared only in the public visibility area of a
class for technical reasons. You control the actual visibility with the
addition CREATE {PUBLIC|PROTECTED|PRIVATE} of the CLASS
DEFINITION statement.
Example
In the following example, class c2 inherits from class c1. The instance
constructor, constructor, is declared explicitly in both classes. It there-
fore has to be implemented in both classes. In addition, the implementa-
tion in c2 has to contain the call of the superclass constructor.
CLASS c1 DEFINITION.
PUBLIC SECTION.
METHODS constructor IMPORTING p1 TYPE any.
...
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD constructor.
...
ENDMETHOD.
ENDCLASS.
CLASS c2 IMPLEMENTATION.
METHOD constructor.
...
super->constructor( p2 ).
...
ENDMETHOD.
ENDCLASS.
Event handlers are methods that can also be called with CALL METHOD,
but which are called primarily by triggering an event of a class or an inter-
face. The only possible formal parameters of an event handler are the
input parameters that are defined as the output parameters of the event.
Syntax
METHODS meth [ABSTRACT|FINAL]
FOR EVENT evt OF {class|ifac}
[IMPORTING {pi} [sender]].
This statement declares the instance method meth as the event handler
evt of class class or interface ifac class. ifac can be any classes or
interfaces that are visible at this point and that contain a visible event evt
as a component.
If event evt is an instance event, event handler meth can handle it for all
objects whose class is class or a subclass of class, or that implement
interface ifac directly or through a superclass. If the event is a static
event, event handler meth can handle it for class and its subclasses, or
for all classes that implement interface ifac.
You can use the additions ABSTRACT and FINAL to make the event han-
dler abstract or final, just like the general methods.
The addition IMPORTING defines the input parameters of the event han-
dler. pi can only be names of formal parameters that you defined as
export parameters of the event with addition EXPORTING for statement
[CLASS-]EVENTS in the declaration of event evt in the class or inter-
face ifac. The additions TYPE/LIKE and OPTIONAL/DEFAULT are not
possible. Any default parameters, the typing of the input parameters, and
whether or not the input parameters are optional are taken from the dec-
laration of the event. You do not have to specify all the output parameters
of the event.
If evt is an instance event, you can also define a formal parameter called
sender as an input parameter of the event handler, in addition to its
explicitly defined output parameters. sender is an implicit output param-
eter of every instance event. It is fully typed as a reference variable that
has class or interface ifac as a static type, as defined in the declaration
of the event handler after EVENT evt OF. If the event handler is called by
an instance event, sender passes on a reference to the triggering object.
Prior to Release 6.10, the static type of formal parameter sender was
determined by the class or interface in which the EVENTS statement
declared the event. In Release 6.10 and later, the event handler deter-
mines the type of its formal parameter itself.
Example
In the example below, class picture contains an event handler handle_
double_click for instance event picture_dblclick of global class
cl_gui_picture. The event handler uses two explicit output parame-
ters of the event, along with the implicit parameter sender, as input
parameters.
Syntax
METHODS meth [FINAL] REDEFINITION.
The redefinition is valid for the subclasses of the redefined class until it is
redefined again. You can continue to redefine a method along a path in
the inheritance tree until it is made final. If you use the addition FINAL
during redefinition, the method is final from the current class and can no
longer be redefined in its subclasses.
Note
Each object reference that points to an object in a subclass addresses the
redefined methods regardless of its static type. This also applies to the
self-reference me->.
Example
In the example below, method m1 of superclass c1 is redefined in subclass
c2. The original implementation is called with super->m1. Both methods
use the private attribute a1 of the respective class. The redefined method
is executed with reference variable oref, which has static type c1 and
dynamic type c2.
CLASS c1 DEFINITION.
PUBLIC SECTION.
METHODS m1 IMPORTING p1 TYPE string.
PRIVATE SECTION.
DATA a1 TYPE string VALUE `c1: `.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD m1.
CONCATENATE a1 p1 INTO a1.
WRITE / a1.
ENDMETHOD.
ENDCLASS.
CLASS c2 IMPLEMENTATION.
METHOD m1.
super->m1( p1 ).
CONCATENATE a1 p1 INTO a1.
WRITE / a1.
ENDMETHOD.
ENDCLASS.
...
CLASS-METHODS
The most general form of the CLASS-METHODS statement lets you define
static methods with any number of input and output parameters.
Syntax
CLASS-METHODS meth
[IMPORTING {parameteri} [PREFERRED PARAMETER p]]
[EXPORTING {parameteri}]
[CHANGING {parameteri}]
[{RAISING|EXCEPTIONS} {exci}].
Note
Static methods cannot be redefined, and therefore cannot be made
abstract or final either.
Functional methods can have any number of input parameters, and have
exactly one return value as output parameter.
Syntax
CLASS-METHODS meth
[IMPORTING {parameteri}]
RETURNING VALUE(r) {TYPE type_spec}|{LIKE dobj_spec}
[{RAISING|EXCEPTIONS} {exci}].
Example
The class described below, circle, contains two functional methods,
circumference and area, and the constants pi.
...
radius = ...
circ = circle=>circumference( radius ).
area = circle=>area( radius ).
Syntax
CLASS-METHODS class_constructor.
This statement is possible only in the public visibility area of the declara-
tion section of a class. It declares the static constructor of the class,
class_constructor.
Each class has a predefined method called class_constructor in its
public visibility area. The explicit declaration enables you to implement its
functionality class-specifically. If you do not declare it explicitly, the static
constructor is blank.
The static constructor is executed once for each class and internal session.
This execution takes place automatically before the first access to the
class. You access a class whenever you generate an instance of that class
or address a static component with the class component selector.
During the first access of a subclass, the system searches for the next-
highest superclass in the inheritance tree whose static constructor has not
been executed yet. The static constructor of the superclass is then exe-
cuted, followed successively by each subsequent subclass down to the
addressed subclass.
Like all static methods, the static constructor can access only the static
components of its class. Furthermore, the static constructor cannot
address its own class explicitly.
Notes
왘 Like instance constructors, static constructors represent another excep-
tion to the rule that all public components along a path in the inherit-
ance tree have to line in the same namespace.
왘 The execution time for the static constructor is indeterminate. The sys-
tem merely guarantees its execution prior to the first access of the
class. The static constructor is usually executed immediately prior to
the access of the class. The static constructor is called at the start of the
respective processing block only if a static attribute of the class is
accessed. We do not recommend writing programs that require the
static constructor to be executed at a specific time.
Example
The static constructor of the class below sets static attribute access_
program to the name of the program of the first internal session that uses
a class during the first access to that class.
Static event handlers are static methods that are called by an event of a
class or an interface. The only possible formal parameters of an event han-
dler are input parameters that are defined as output parameters of the
event.
CLASS-METHODS meth
FOR EVENT evt OF {class|ifac}
[IMPORTING {pi} [sender]].
This statement declares the static method meth as the event handler evt
of class or interface ifac. The syntax and meaning of the additions are
identical to those in the declaration of instance methods as event han-
dlers.
Example
In the class described below, dialog_box, a static event handler close_
box is defined for the event. This event is triggered when the user
attempts to close a dialog box of the GUI control framework (CFW).
7.4.2 Events
You use the EVENTS and CLASS-EVENTS statements to declare events.
When you declare an event in a class, the methods of that class can trig-
ger the event, which in turn triggers the execution of event handlers. Dur-
ing the declaration, you can define output parameters for an event that
are passed on to the event handler as actual parameters when the event is
triggered.
EVENTS
The EVENTS statement declares instance events. Instance events are tied
to objects. They can be triggered only in instance methods of the same
class.
Syntax
EVENTS evt [EXPORTING { VALUE(pi) typing
[ OPTIONAL|{DEFAULT defi}] } ].
When you trigger an event with the RAISE EVENT statement, you have to
specify suitable actual parameters for all non-optional output parameters.
You can also specify any desired optional parameters. Optional parame-
ters for which no actual parameter is specified are set to their type-spe-
cific initial value or to the default parameter, defi.
When you declare an event handler with the addition FOR EVENT OF in
the [CLASS-]METHODS statement, you can define the output parameters
of the event as the input parameters of the event handler; in this case, the
attributes of the input parameters are copied to the output parameters
defined in EVENTS.
Prior to Release 6.10, the static type of implicit parameter sender was
defined by the class or interface where the EVENTS statement was listed.
In Release 6.10 and later, the static type of input parameter sender is
defined by the addition FOR EVENT OF in the [CLASS-]METHODS state-
ment.
Note
The dynamic type of the implicit formal parameter, sender, is always the
class of the object in which the event is triggered.
Example
In the interface below, window, three events are declared, each with an
explicit, non-optional output parameter, status. Class dialog_window
implements interface window. Interface window_handler contains event
handlers that import both the explicit parameter, status, and the
implicit parameter, sender. The static type of input parameter sender is
class dialog_window. Prior to Release 6.10, interface window is the static
type.
INTERFACE window.
EVENTS: minimize EXPORTING VALUE(status) TYPE i,
maximize EXPORTING VALUE(status) TYPE i,
restore EXPORTING VALUE(status) TYPE i.
ENDINTERFACE.
INTERFACE window_handler.
METHODS: minimize_window
FOR EVENT window~minimize OF dialog_window
IMPORTING status sender,
maximize_window
FOR EVENT window~maximize OF dialog_window
IMPORTING status sender,
restore
FOR EVENT window~restore OF dialog_window
IMPORTING status sender.
ENDINTERFACE.
CLASS-EVENTS
The CLASS-EVENTS statement declares static events. Static events are not
tied to objects. They can be triggered in all methods of the same class.
Syntax
CLASS-EVENTS evt [EXPORTING { VALUE(pi) typing
[ OPTIONAL|{DEFAULT defi}] } ].
Note
Static events do not have an implicit formal parameter called sender.
INTERFACES
Syntax
INTERFACES ifac
{ { [ABSTRACT METHODS {methi}]
[FINAL METHODS {methj}] }
| [ALL METHODS {ABSTRACT|FINAL}] }
[DATA VALUES {attri = vali}].
ifac can be any local or global interfaces that are visible at this point. The
implementation makes the components of the interfaces public compo-
nents of the class. An interface component named comp has the name
ifac~comp in the class: ifac is the name of the interface and the ~ char-
acter is the interface component selector. A class has to implement all
methods of the interface in its implementation section, provided it is not
declared as abstract.
You can use the additions ABSTRACT METHODS and FINAL METHODS to
make individual instance methods of the interface, methi, abstract or final
in the implementing class. The same rules apply as for the additions
ABSTRACT and FINAL of the METHODS statement. In particular, when you
make an interface method abstract, the entire class has to be abstract,
and you cannot list an interface method after both ABSTRACT METHODS
and FINAL METHODS at the same time. Instead of making individual
instance methods abstract or final in the class, you can use the addition
ALL METHODS {ABSTRACT|FINAL} to make all the interface methods
either abstract or final.
You can use the addition DATA VALUES to assign initial values to the indi-
vidual attributes, attri. This addition has the same function for instance
attributes as the addition VALUE of the DATA statement for internal class
attributes. If you declare a constant with the CONSTANTS statement in the
interface, you cannot list it after the addition DATA VALUES.
Notes
A class can implement any number of different interfaces. All the inter-
faces implemented in a class are equally valid on one level. If an interface
implemented in a class, ifac, is a composite—that is, it contains compo-
nent interfaces—these interfaces are implemented as individual interfaces
in the class, regardless of their nesting hierarchy. As a result, their compo-
nents are not addressed through the name ifac, but instead through the
name of the component interfaces. Multiple use of the interface compo-
nent selector in an identifier (such as ifac1~ifac2~comp) is generally not
supported.
Each interface exists only once in a class, and each interface component
comp can be uniquely addressed with the name ifac~comp. Even a com-
ponent of an interface that is seemingly implemented several times in a
class—because it is an interface component of one or more other inter-
faces, for example—really exists only once.
Syntax
INTERFACES ifac.
Notes
Each interface and its components appear only once in a composite inter-
face. Even an interface that is seemingly implemented several times in an
interface, because it is an interface component of one or more other
interfaces, really exists only once.
Because there are no separate namespaces for global and local interfaces,
you have to make sure that composition of local interfaces does not result
in combinations of global and local interfaces with identical names, since
they cannot lie on the same level in their implementation.
Example
The following example illustrates how you can use the INTERFACES state-
ment to compose and implement interfaces. Class c1 implements the
composite interfaces i2 and i3. Although i1 is a component interface of
i2 and i3, it exists only once in class c1. A reference variable iref1 with
static type i1 is used to generate an object class c1 and call method
i1~m1, which is implemented there.
INTERFACE i1.
METHODS m1.
ENDINTERFACE.
INTERFACE i2.
INTERFACES i1.
METHODS m2.
ENDINTERFACE.
INTERFACE i3.
INTERFACES i1.
METHODS m3.
ENDINTERFACE.
CLASS c1 DEFINITION.
PUBLIC SECTION.
INTERFACES: i2, i3.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD i1~m1.
...
ENDMETHOD.
METHOD i2~m2.
...
ENDMETHOD.
METHOD i3~m3.
...
ENDMETHOD.
ENDCLASS.
...
ALIASES
Syntax
ALIASES alias FOR ifac~comp.
An alias name belongs to the components of the class and the interface.
It lies within the same namespace as the other components and is inher-
ited to subclasses. You can define an alias name in every visibility area of
a class.
Note
You cannot use the alias name in the implementation of interface meth-
ods in the implementation section of classes. You always have to specify
the complete identifier, ifac~meth, in the METHOD statement.
Example
In the example below, alias names are declared for the methods of the
integrated and implemented interfaces in interfaces i2 and i3 and class
c1. The interface methods are implemented with the interface compo-
nent selector in the METHODS statements in the implementation section
of the class. The alias names of the class can be used within the methods.
INTERFACE i1.
METHODS meth.
ENDINTERFACE.
INTERFACE i2.
INTERFACES i1.
ALIASES m1 FOR i1~meth.
METHODS meth.
ENDINTERFACE.
INTERFACE i3.
INTERFACES i2.
ALIASES: m1 FOR i2~m1,
m2 FOR i2~meth.
METHODS meth.
ENDINTERFACE.
CLASS c1 DEFINITION.
PUBLIC SECTION.
INTERFACES i3.
ALIASES: m1 FOR i3~m1,
m2 FOR i3~m2,
m3 FOR i3~meth.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD i1~meth.
... m2( ) ...
ENDMETHOD.
METHOD i2~meth.
... m3( ) ...
ENDMETHOD.
METHOD i3~meth.
... m1( ) ....
ENDMETHOD.
ENDCLASS.