Beruflich Dokumente
Kultur Dokumente
This is a step-by-step guide to learn ABAP Objects. Typically used to enable ABAP
developers to place their first step into ABAP Objects. This guide includes examples
with ready to use source codes (with output) to explain every topic.
PREREQUISITES
This guide assumes that the reader has a good knowledge of ABAP Workbench
Fundamentals and has hands on experience of creating Report Programs as well as
Module Pool Programs.
AUTHER
AUTHER:
Vikrant Trivedi
SAP Technical Consultant
(ABAP + Web Dynpro + EP)
COMPANY:
CREATED ON:
18 - April - 2008
CONTENTS
Basic Terminology
Classes
Objects / Instances
Attributes
Methods
Constructor
Object Identity and Reference Semantics
Visibility
Events
Inheritance
Polymorphism
Interfaces
ALV Grid Control
ALV Grid Control Using Events
ALV Grid Control Using Field Catalogs
BASIC TERMINOLOGY
For a long time it was standard practice in software development to subdivide
software systems according to the system's functions. Object-orientation takes another
approach. Instead of concentrating on functions, the object-oriented approach
concentrates on data abstractions using - so-called Classes.
CLASSES
Classes are the central element of object-orientation. A Class describes a general
element or a general concept. Classes realize an abstract data type. Classes contain
components like: Attributes, Methods and Events. These components are described
later in this document. In ABAP Objects classes are made up of a definition and an
implementation part.
CLASS CL_CLASSNAME DEFINITION.
ENDCLASS.
CLASS CL_CLASSNAME IMPLEMENTATION.
ENDCLASS.
OBJECTS / INSTANCES
An object is nothing more than an instance of a Class.
Object - A person, place, thing, concept, or event that is applicable to the system at
hand. Objects both know things (i.e., they have data) and they do things (i.e. they
have functionality).
In ABAP Objects, objects are created with the command CREATE OBJECT. The
developer receives an object reference as a result of its creation:
DATA: instance TYPE REF TO CL_CLASSNAME.
START-OF-SELECTION.
CREATE OBJECT instance.
ATTRIBUTES
Attributes can take on values within an object at runtime. The sum of all attributes and
their values describes the state of an object.
Attributes can be defined as instance dependent as well as Class dependent. Class
attributes (Class attributes are also called static attributes.) are not tied to a single
instance, rather they "belong" to all instances of the Class. These attributes exist only
once in main memory. Instance-dependent attributes exist once per instance and are
tied to a single instance.
In ABAP Objects you differentiate between instance-dependent and class-dependent
attributes by means of the ABAP keywords DATA or CLASS-DATA to be used in
the definition part:
Program : 001
Code listing for: Z_001_SIMPLE_CLASS
Description: SIMPLE CLASS WITH ATTRIBUTES
REPORT Z_001_SIMPLE_CLASS.
TYPES: TY_NAME(50) TYPE C.
*---------------------------------------------------------------*
"CL_NAME DEFINITION
*---------------------------------------------------------------*
"CL_NAME IMPLEMENTATION
30
NAME : VIKRANT
ATTRIBUTES OF INSTANCE 2 :::
COUNT :
30
NAME : TULSI
ATTRIBUTES OF INSTANCE 3 :::
COUNT :
30
NAME : ANUSHVI
METHODS
As well as attributes, Classes have so-called Methods. While attributes describe the
static structure of a class and its objects, Methods describe the behavior of objects
within a class. With the help of methods, the system provides operations, services and
functions. Via methods, a user can manipulate the objects in a class or also the class
itself. As for attributes, there are instance-dependent as well as class-dependent
(static) methods. ABAP Objects differentiate between instance-dependent and classdependent methods via the ABAP keywords METHODS or CLASS-METHODS used
in the definition part.
In order to carry out instance-dependent (or instance-dependent) methods, the calling
program needs a specific instance of the class. That is, the calling program must have
a defined reference variable that points to a specific instance. Class methods are not
instance-dependent. They can be called at any time by a user. To see how the syntax
calls the various method types, see the following example.
Program : 002
Code listing for: Z_002_METHODS
Description: EXAMPLE SHOWING USE OF METHODS
REPORT Z_002_METHODS.
TYPES: TY_NAME(50) TYPE C,
BOOLEAN(1) TYPE C.
CONSTANTS: CO_TRUE TYPE C VALUE 'X',
CO_FALSE TYPE C VALUE ' '.
*---------------------------------------------------------------*
"CL_NAME DEFINITION
*---------------------------------------------------------------*
"CL_NAME IMPLEMENTATION
START-OF-SELECTION.
DATA BOOL TYPE BOOLEAN.
" CHECK IF ANY INSTANCE OF THIS CLASS HAS BEEN CREATED BEFORE
CALL METHOD CL_NAME=>IS_CLASS_INITIATED
IMPORTING
RE_BOOL = BOOL.
IF BOOL = CO_FALSE.
" CREATE INSTANCE OF THIS CLASS, IF NO INSTANCE EXIST
DATA: INSTANCE TYPE REF TO CL_NAME,
NAME TYPE TY_NAME.
CREATE OBJECT INSTANCE.
" SET VALUE FOR NAME ATTRIBUTE
CALL METHOD INSTANCE->SET_NAME
EXPORTING
IM_NAME = 'VIKRANT J. TRIVEDI'.
" GET VALUE OF NAME ATTRIBUTE
CALL METHOD INSTANCE->GET_NAME
IMPORTING
EX_NAME = NAME.
WRITE: / 'NAME : ' , NAME.
" CLEAR MEMORY OCCUPIED BY OBJECTS
CLEAR: INSTANCE.
ENDIF.
CONSTRUCTOR
Objects must be created at runtime (using CREATE OBJECT). With their creation they
also get their own identity. However, there are no fixed attribute values linked to the
identity. You are probably already wondering how objects get to their initial state.
How do objects recognize their initial attribute values?
TheConstructor concept exists specifically to answer this question. The constructor is
a method which runs automatically during the creation of an object. The constructor
allows you to define IMPORTING-parameters.
In ABAP Objects you differentiate between instance-dependent and class-dependent
constructors via the language elements METHODS{{ }}and CLASS-METHODS to be used
in the definition part and via their namesconstructor and CLASS_CONSTRUCTOR:
The class constructor is called by the first access to a class element (method, attribute,
event, and object), the (instance) constructor by the creation of an object (CREATE
OBJECT).
Program : 003
Code listing for: Z_003_CONSTRUCTOR
Description: EXAMPLE OF USING CONSTRUCTOR
REPORT Z_003_CONSTRUCTOR.
TYPES: TY_NAME(50) TYPE C.
*---------------------------------------------------------------*
"CL_NAME DEFINITION
*---------------------------------------------------------------*
"CL_NAME IMPLEMENTATION
START-OF-SELECTION.
" CREATE INSTANCE OF THIS CLASS, IF NO INSTANCE EXISTS.
DATA: INSTANCE1 TYPE REF TO CL_NAME,
INSTANCE2 TYPE REF TO CL_NAME,
NAME1 TYPE TY_NAME,
NAME2 TYPE TY_NAME.
CREATE OBJECT INSTANCE1
EXPORTING
IM_NAME = 'VIKRANT J. TRIVEDI'.
CREATE OBJECT INSTANCE2
EXPORTING
IM_NAME = 'TULSI V. TRIVEDI'.
" GET VALUE OF NAME ATTRIBUTE
CALL METHOD INSTANCE1->GET_NAME
IMPORTING
EX_NAME = NAME1.
CALL METHOD INSTANCE2->GET_NAME
IMPORTING
EX_NAME = NAME2.
" DISPLAY ATTRIBUTES OF INSTANCE1
WRITE: 'ATTRIBUTES OF INSTANCE 1 : ',
/ 'COUNT : ', INSTANCE1->I_COUNT,
/ 'NAME : ' , NAME1.
SKIP.
SKIP.
" DISPLAY ATTRIBUTES OF INSTANCE2
WRITE: 'ATTRIBUTES OF INSTANCE 2 : ',
/ 'COUNT : ', INSTANCE2->I_COUNT,
/ 'NAME : ' , NAME2.
" CLEAR MEMORY OCCUPIED BY OBJECTS
CLEAR: INSTANCE1,
INSTANCE2.
10
10
Program : 004
Code listing for: Z_004_OBJECT_IDENTITY
Description: OBJECT IDENTITY & REFERENCE SEMANTICS
REPORT Z_004_OBJECT_IDENTITY.
TYPES: TY_NAME(50) TYPE C.
*---------------------------------------------------------------*
"CL_NAME DEFINITION
*---------------------------------------------------------------*
"CONSTRUCTOR
"CL_NAME IMPLEMENTATION
START-OF-SELECTION.
CREATE OBJECT INSTANCE1
EXPORTING
IM_NAME = 'VIKRANT'.
CREATE OBJECT INSTANCE2
EXPORTING
IM_NAME = 'VIKRANT'.
" Reference semantics !!!
IF INSTANCE1 = INSTANCE2.
WRITE 'This will never print, as instance1 refers to a
different object than instance2.'.
ENDIF.
" Attribute values are the same !!!
IF INSTANCE1->NAME = INSTANCE2->NAME.
WRITE 'Attribute values of instance1 and instace2 are same.'.
ENDIF.
INSTANCE3 = INSTANCE1.
IF INSTANCE3 = INSTANCE1.
WRITE 'Both references instance1 and instace3 refer to the
same object and are therefore identical.'.
ENDIF.
VISIBILITY
An important feature of object-orientation is the encapsulation of attributes and
methods - ultimately of functionality - in classes. A class guarantees its user specific
properties and specific behavior. The sum of these properties is called the class
interface. The Visibility mechanism defines the class interface which is available to
the users.
There are three commonly defined types of visibility in object-oriented technology:
Public
The relevant class component (attribute, method, event etc.) is visible to all classes.
Protected
The relevant class component (attribute, method, event etc.) is visible to the class
itself and all inheritors. (We will return to the terms Inheritor and Inheritance later in
this document.)
Private
The relevant class component (attribute, method, event etc.) is only visible to the class
itself.
Program : 005
Code listing for: Z_005_VISIBILITY
Description: COMPONENT VISIBILITY
*--------------------------------------------------------------* In this example the PRIVATE attribute NAME is hidden from the
* users. Access to the information it contains is realized via
* the PUBLIC method SET_NAME & GET_NAME.
*--------------------------------------------------------------*
* TYPES OF VISIBILITY :
* (1) PUBLIC : class component is visible to all classes.
* (2) PRIVATE : class component is visible to the class itself.
* (3) PROTECTED : class component is visible to class itself and
*
*
*--------------------------------------------------------------REPORT Z_005_VISIBILITY.
TYPES: TY_NAME(50) TYPE C.
*---------------------------------------------------------------*
"CL_NAME DEFINITION
*---------------------------------------------------------------*
"CL_NAME IMPLEMENTATION
START-OF-SELECTION.
" CREATE INSTANCE OF THIS CLASS, IF NO INSTANCE EXIST
DATA: INSTANCE TYPE REF TO CL_NAME,
NAME TYPE TY_NAME.
CREATE OBJECT INSTANCE.
" SET VALUE FOR NAME ATTRIBUTE
CALL METHOD INSTANCE->SET_NAME
EXPORTING
IM_NAME = 'VIKRANT J. TRIVEDI'.
CLASS CL_NAME
"CL_NAME
*---------------------------------------------------------------*
"CL_NAME
"PROCESS_EVENT
"CL_NAME IMPLEMENTATION
"CL_CLASS1 DEFINITION
*---------------------------------------------------------------*
"CONSTRUCTOR
"CL_CLASS1 IMPLEMENTATION
*---------------------------------------------------------------*
PUBLIC SECTION.
CLASS-METHODS INITIALISE.
PRIVATE SECTION.
CLASS-METHODS PROCESS_EVENT FOR EVENT OBJECT_CREATED
OF CL_CLASS1. " REGISTERS METHOD
ENDCLASS.
"CL_CLASS2 DEFINITION
*---------------------------------------------------------------*
"INITIALISE
"PROCESS_EVENT
"CL_CLASS2 IMPLEMENTATION
EVENT FIRED.
In the above program, with the help of the class method initialize, the class
CL_CLASS2 registers the method PROCESS_EVENT at the event OBJECT_CREATED for all
instances of the class CL_CLASS1. When an object is created for the class CL_CLASS1
(CREATE OBJECT instance.), the event OBJECT_CREATED is raised in the constructor.
The consequence is that the method PROCESS_EVENT{{ }}belonging to the class
CL_CLASS2 is executed.
INHERITANCE
Inheritance defines the relationship between classes, in which a class (subclass) uses
the structure and behavior that has already been defined in one or more other classes
(superclasses). So simply this means "Inheritance is about reuse!".
Allow me to use a concrete example to explain inheritance: Collection.
A collection is any number of objects (more precisely object references). However,
there could be many types of collection. Therefore, I will implement each type of
collection as a class. In principle this approach is correct. However, you will soon
establish that all collections have several components in common like:
1.
2.
3.
Each class has a method which identifies the number of object references
in the collection and so on.
Inheritance is the solution to this situation. You implement all of the similarities in the
class which is Superclass. You then implement the individual types of collection in
their own classes which are Subclassesof the Superclass. As a subclass, these classes
inherit all of the components of the Superclass. Attributes, methods and events are
inherited. In addition, you can implement additional attributes, methods and events in
the subclass.
POLYMORPHISM
Polymorphism occurs, where classes implement the same functionality with different
methods (one functionality, several methods but the same name). This can occur via
an inheritance relationship, in that the methods belonging to the superclass are
redefined in the subclasses and implemented differently. ABAP Objects requires the
method names to be the same and the signature to be the same (signature = method
interface).
Polymorphism can be achieved in 2 ways:
(1) Two independent classes implement methods with the same names and the same
signature with the intention, that the methods should be called dynamically from a
third location.
(2) A superclass implements a method, and in a subclass you want to re-implement
the same method, as the superclass implementation is not suitable for the subclass.
The first scenario will not occur very often in ABAP Objects, as the interface concept
was created precisely for such cases.
Program : 008
Code listing for: Z_008_INHERIT_POLY
Description: EXAMPLE OF INHERITANCE & POLYMORPISM
REPORT Z_008_INHERIT_POLY.
TYPES: BEGIN OF TY_NAME,
NAME(50) TYPE C,
END OF TY_NAME.
TYPES: TY_NAMES TYPE TY_NAME OCCURS 0.
*---------------------------------------------------------------*
"CL_COLLECTION DEFINITION
*---------------------------------------------------------------*
*----------------------------------------------------------------
"ADD
METHOD DISPLAY.
DATA: CNT TYPE I.
DESCRIBE TABLE IT_NAMES LINES CNT.
IF CNT > 0.
DATA WA_NAME LIKE LINE OF IT_NAMES.
ULINE.
WRITE 10 'DISPLAYING DATA'.
ULINE.
WRITE 10 'NAMES'.
ULINE.
LOOP AT IT_NAMES INTO WA_NAME.
WRITE /10 WA_NAME-NAME.
ENDLOOP.
ENDIF.
ENDMETHOD.
ENDCLASS.
"DISPLAY
"CL_COLLECTION IMPLEMENTATION
*---------------------------------------------------------------*
ENDCLASS.
"CL_NAME DEFINITION
*---------------------------------------------------------------*
"ADD
"CL_NAME IMPLEMENTATION
SKIP.
SKIP.
CALL METHOD INSTANCE->DISPLAY.
Program Output : 008
ADDED VIKRANT TRIVEDI FOR THE 1ST TIME.
ADDED TULSI TRIVEDI FOR THE 1ST TIME.
ADDED ANUSHVI TRIVEDI FOR THE 1ST TIME.
ADDED VIKRANT TRIVEDI FOR THE 2ND TIME.
ADDED TULSI TRIVEDI FOR THE 2ND TIME.
ADDED ANUSHVI TRIVEDI FOR THE 2ND TIME.
----------------------------------------------------------------DISPLAYING DATA
----------------------------------------------------------------NAMES
----------------------------------------------------------------VIKRANT TRIVEDI
TULSI TRIVEDI
ANUSHVI TRIVEDI
In the above example, I have partially implemented the class CL_COLLECTION and its
inheritor class CL_NAME. The method ADD{{ }}belonging to the class CL_COLLECTION
is redefined by the method ADD{{ }}belonging to the class CL_NAME. In the method
ADDbelonging to the CL_NAME the method ADD belonging to the superclass
CL_COLLECTION is called via CALL METHOD SUPER->ADD.
INTERFACES
TheInterface concept describes a class interface. You can define the same components
in an interface that you can in classes, however without implementing them.
Classes can implement interfaces, and subsequently be addressed via these interfaces.
This opens an additional mechanism of polymorphism, however without being
dependent on inheritance. This combination of classes with simple inheritance and
interfaces is more highly regarded by many experts than full multiple inheritances.
In addition to object references (DATA: instance TYPE REF TO CL_CLASS) there are
also Interface References (DATA: reference TYPE REF TO CL_INTERFACE). A class
which implements a specific interface can be addressed via this interface reference.
Using such an interface reference, you can access the components defined in the
interface. In this way a user can view different classes through the 'spectacles' of an
interface and address them in a uniform manner.
Interfaces therefore define specific, generic functionality. In contrast to classes,
interfaces generally have not only many users, but also many implementers.
Program : 009
Code listing for: Z_009_INTERFACE
Description: EXAMPLE OF INTERFACE
*--------------------------------------------------------------* Report Z_009_INTERFACE
*--------------------------------------------------------------*
* The Interface concept describes a class interface. You can
* define the same components in an interface that you can in
* classes, however without implementing them. Classes can
* Implement interfaces, and subsequently be addressed via these
* interfaces.
*
*--------------------------------------------------------------* IN THIS EXAMPLE : The Interface IF_INTERFACE is implemented
* via the classes CL_CLASS1 And CL_CLASS2.
*--------------------------------------------------------------REPORT Z_009_INTERFACE.
*---------------------------------------------------------------*
INTERFACE IF_INTERFACE
*---------------------------------------------------------------INTERFACE IF_INTERFACE.
METHODS DISPLAY.
ENDINTERFACE.
"IF_INTERFACE
*---------------------------------------------------------------*
"CL_CLASS1 DEFINITION
*---------------------------------------------------------------*
"IF_INTERFACE~DISPLAY
"CL_CLASS1 IMPLEMENTATION
*---------------------------------------------------------------*
ENDCLASS.
"CL_CLASS2 DEFINITION
*---------------------------------------------------------------*
"IF_INTERFACE~DISPLAY
"CL_CLASS2 IMPLEMENTATION
The ALV Grid Control has a number of interactive standard functions that list users
frequently use, for example, printing, and export. Developers can hide these standard
functions if they wish. However, you can modify the implementations on an
application-specific basis if required. You can also add your own functions to the
application toolbar.
Application controls like ALV Grid Control, Tree Controls, and Picture Controls must
be embedded in a Container Control, which in turn must be connected with the screen.
Container Controls form the technical connection between a screen and an application
control. There are different types of container controls. All of these types encapsulate
basic control functions (for example, scroll bars).
In the following sections, we will work trough a standard case as an example:
Positioning an ALV Grid Control in a screen area with a fixed size. To do this, an
instance of each of the global classes CL_GUI_CUSTOM_CONTAINER and CL_GUI_ALV_GRID must be generated.
For a basic standard display, it is enough to program the following steps:
1. Define a custom control area on your screen using the screen painter's
graphical full screen editor.
1. Generate an instance of the CL_GUI_CUSTOM_CONTAINER class and give
the constructor the name of the custom control area you have defined.
1. Generate an instance of the class CL_GUI_ALV_GRID and assign the
constructor the reference to the container control instance you have just
generated.
1. Call the SET_TABLE_FOR_FIRST_DISPLAY method of the Grid Control
instance and assign it the internal standard table and application data.
If this method has a global line type, you can give it the name of this global structure.
The field catalog will then be set up by the grid control instance itself.
If the contents of the internal table change during the rest of the program run, it is
enough to call the method REFRESH_TABLE_DISPLAY in the corresponding
dialog step, to update the display accordingly.
Program : 010
Code listing for: Z_010_ALV_GRID_CONTROL
Description: EXAMPLE OF ALV GRID CONTROL
*---------------------------------------------------------------*
MODULE POOL
Z_010_ALV_GRID_CONTROL
TOP INCLUDE
Z_010_ALV_GRID_CONTROL_TOP
*----------------------------------------------------------------------------------PROGRAM Z_010_ALV_GRID_CONTROL.
TABLES: SFLIGHT.
DATA: OK_CODE TYPE SY-UCOMM,
IT_SFLIGHT TYPE STANDARD TABLE OF SFLIGHT,
R_CONTAINER TYPE REF TO CL_GUI_CUSTOM_CONTAINER,
R_GRID TYPE REF TO CL_GUI_ALV_GRID.
*-------------------------------------------------------------------------------
PBO INCLUDE
Z_010_ALV_GRID_CONTROL_O01
*-------------------------------------------------------------------------------*---------------------------------------------------------------*
Module
SHOW_ALV OUTPUT
= IT_SFLIGHT.
ENDMODULE.
*---------------------------------------------------------------*
Module
GET_DATA OUTPUT
*---------------------------------------------------------------*
Module
CREATE_OBJECTS OUTPUT
*---------------------------------------------------------------*
Module
STATUS_0101 OUTPUT
*---------------------------------------------------------------------------*
PAI INCLUDE
Z_010_ALV_GRID_CONTROL_I01
*---------------------------------------------------------------------------*---------------------------------------------------------------*
Module
USER_COMMAND_0101 INPUT
USING
SFLIGHT-CARRID.
CALL METHOD R_GRID->REFRESH_TABLE_DISPLAY.
WHEN 'EXIT'.
LEAVE PROGRAM.
ENDCASE.
ENDMODULE.
*----------------------------------------------------------------------------------*
FORM INCLUDE
Z_010_ALV_GRID_CONTROL_F01
*----------------------------------------------------------------------------------*---------------------------------------------------------------* FORM
: GET_DATA
An ALV Grid Control can react to a user double-clicking the mouse button. One
possible reaction is that a subsequent processing is triggered in which additional
information is displayed. The event DOUBLE_CLICK is caught using a handler
method. A handler method can be either a class method (static method) or an object's
instance method. If a class method is defined as a handler method, there is no need to
instantiate an object of the handling class, to use the method. To create a handler
object for an event, you must first of all define a class. This class has a public method
(in the PUBLIC SECTION) that can react to an event. In the handler method's
implementation, create the source text that will run when you trigger the event. The
method receives the information delivered by the event from the position of the
mouse when the user executes a double-click, and in the control example, generates
an information message that displays the line and field where the mouse is clicked.
Program : 011
Code listing for: Z_011_ALV_GRID_EVENT
Description: EXAMPLE OF ALV GRID CONTROL
*---------------------------------------------------------------*
MODULE POOL
Z_011_ALV_GRID_EVENT
*---------------------------------------------------------------PROGRAM Z_011_ALV_GRID_EVENT.
*----------------------------------------------------------------
"CL_EVENT_HANDLER DEFINITION
*---------------------------------------------------------------*
"ON_DOUBLE_CLICK
METHOD ON_RIGHT_CLICK.
MESSAGE 'RIGHT MOUSE BUTTON HAS CLICKED !!!' TYPE 'I'.
ENDMETHOD.
"ON_RIGHT_CLICK
ENDCLASS.
"CL_EVENT_HANDLER IMPLEMENTATION
*---------------------------------------------------------------*
INCLUDE PROGRAMS
PBO INCLUDE
Z_011_ALV_GRID_EVENT_O01
*-----------------------------------------------------------------------*--------------------------------------------------------------*
Module
SHOW_ALV OUTPUT
= IT_SFLIGHT.
" SHOW_ALV OUTPUT
*---------------------------------------------------------------*
Module
GET_DATA OUTPUT
*---------------------------------------------------------------*
Module
CREATE_OBJECTS OUTPUT
*---------------------------------------------------------------*
Module
STATUS_0101 OUTPUT
*-----------------------------------------------------------------------*
PAI INCLUDE
Z_011_ALV_GRID_EVENT_I01
*-----------------------------------------------------------------------*---------------------------------------------------------------*
Module
USER_COMMAND_0101 INPUT
*----------------------------------------------------------------
*----------------------------------------------------------------------------*
FORM INCLUDE
Z_011_ALV_GRID_EVENT_F01
*----------------------------------------------------------------------------*---------------------------------------------------------------* FORM
: GET_DATA
ENDIF.
ENDFORM. "GET_DATA
ALV GRID CONTROL USING FIELD CATALOGS
The internal table with the data to be displayed can have a user-specific line type. In
order for the proxy instance to satisfactorily format the data it receives during the
screen output or when a print list is created, it requires relevant information known as
the field catalog.
You can have the proxy instance automatically generate the field catalog. For line
types that are defined in the ABAP Dictionary, you only need to inform the proxy
instance of the structure's name in the ABAP Dictionary.
Alternatively, or in addition to this, you can provide the proxy instance with this
display information using an additional internal table. For the sake of simplicity, we
will call this additional table a field catalog. The global data type of this internal table
is LVC_T_FCAT. Its line type is LVC_S_FCAT.
Typical examples of where you need to transfer a field catalog include:
The internal table with data has a line type with a dictionary reference, but the
display of the column position or heading is different.
The internal table has (exclusive or additional) columns that are not contained
in a dictionary structure.
For each column in the data table that deviates from an underlying dictionary
structure or is not available in a dictionary structure, the field catalog must contain a
line that determines the technical characteristics and other column format information.
Program : 012
Code listing for: Z_012_ALV_FIELDCATALOG
Description: EXAMPLE OF ALV USING FIELDCATALOG
*---------------------------------------------------------------*
SCREEN 101 : FLOW LOGIC
*---------------------------------------------------------------PROCESS BEFORE OUTPUT.
MODULE STATUS_0101.
MODULE GET_DATA.
MODULE CREATE_OBJECTS.
MODULE CREATE_FIELDCAT.
MODULE DISPALY_ALV.
*---------------------------------------------------------------------*
MODULE POOL
Z_012_ALV_FIELDCATALOG
TOP INCLUDE
Z_012_ALV_FIELDCATALOG_TOP
*--------------------------------------------------------------------------PROGRAM Z_012_ALV_FIELDCATALOG.
TABLES SPFLI.
TYPES: BEGIN OF TY_SPFLI,
CARRID
TYPE SPFLI-CARRID,
CONNID
TYPE SPFLI-CONNID,
*--------------------------------------------------------------------------*
PBO INCLUDE
Z_012_ALV_FIELDCATALOG_O01
*--------------------------------------------------------------------------*---------------------------------------------------------------*
Module
STATUS_0101 OUTPUT
*---------------------------------------------------------------*
Module
GET_DATA OUTPUT
*---------------------------------------------------------------*
Module
CREATE_OBJECTS OUTPUT
*---------------------------------------------------------------*
Module
CREATE_FIELDCAT OUTPUT
*----------------------------------------------------------------
*---------------------------------------------------------------*
Module
DISPALY_ALV OUTPUT
*----------------------------------------------------------------------------*
FORM INCLUDE
Z_012_ALV_FIELDCATALOG_F01
*----------------------------------------------------------------------------*---------------------------------------------------------------* FORM
: GET_DATA
: CREATE_FIELDCATALOG
WA_FIELDCAT-FIELDNAME = 'CARRID'.
WA_FIELDCAT-REF_FIELD = 'CARRID'.
WA_FIELDCAT-REF_TABLE = 'SPFLI'.
WA_FIELDCAT-COL_POS = 0.
WA_FIELDCAT-FIX_COLUMN = 'X'.
APPEND WA_FIELDCAT to IT_FIELDCAT.
CLEAR WA_FIELDCAT.
WA_FIELDCAT-FIELDNAME = 'CONNID'.
WA_FIELDCAT-REF_FIELD = 'CONNID'.
WA_FIELDCAT-REF_TABLE = 'SPFLI'.
WA_FIELDCAT-COL_POS = 1.
WA_FIELDCAT-FIX_COLUMN = 'X'.
APPEND WA_FIELDCAT to IT_FIELDCAT.
CLEAR WA_FIELDCAT.
WA_FIELDCAT-FIELDNAME = 'COUNTRY FROM'.
WA_FIELDCAT-REF_FIELD = 'COUNTRYFR'.
WA_FIELDCAT-REF_TABLE = 'SPFLI'.
WA_FIELDCAT-COL_POS = 2.
WA_FIELDCAT-FIX_COLUMN = 'X'.
APPEND WA_FIELDCAT to IT_FIELDCAT.
CLEAR WA_FIELDCAT.
WA_FIELDCAT-FIELDNAME = 'COUNTRY TO'.
WA_FIELDCAT-REF_FIELD = 'COUNTRYTO'.
WA_FIELDCAT-REF_TABLE = 'SPFLI'.
WA_FIELDCAT-COL_POS = 3.
WA_FIELDCAT-FIX_COLUMN = 'X'.
APPEND WA_FIELDCAT to IT_FIELDCAT.
CLEAR WA_FIELDCAT.
ENDFORM. "CREATE_FIELDCATALOG
*---------------------------------------------------------------* FORM
: DISPLAY_ALV
EXPORTING
I_STRUCTURE_NAME = 'SFLIGHT'
CHANGING
IT_OUTTAB
= IT_SPFLI
IT_FIELDCATALOG = IT_FIELDCAT.
ENDFORM. "DISPLAY_ALV
*---------------------------------------------------------------*
Form CREATE_OBJECTS
*---------------------------------------------------------------FORM CREATE_OBJECTS .
CREATE OBJECT R_CONTAINER
EXPORTING CONTAINER_NAME = 'CC_ALV'.
CREATE OBJECT R_ALV
EXPORTING I_PARENT = R_CONTAINER.
ENDFORM.
" CREATE_OBJECTS
Labels parameters