A Guide to the New ALV Grid Control Part 1

Problems with ABAP output and why the ALV Grid Control can help

In this Blog series I will dive deeply into the ALV Grid Control and elaborate on its advantages in ABAP list
processing. Lets begin by looking at some problems with Classical list processing
Within an SAP system there is a lot of data that needs to be reviewed, maintained, and interpreted. You know what
Im talking about inventory data, controlling data, accounting data, employee addresses, and so on and so forth.
The bigger a company, the greater the amount of data that needs to be output for review and analysis.
Within the context of certain applications, the terms output and list can be synonymous. When I took my very first
ABAP class at SAP Education, I learned that the term list denotes an output page that has been created using ABAP
statements like WRITE, POSITION, or FORMAT, and text lines are buffered in a list buffer before a system program
called the ABAP list processor steps in to perform various run-time activities. Lists created in this way are often
referred to as classical lists (everything in SAP that is okd is lovingly termed Classical) and represent the standard
output method of data.
If you have dealt with list formatting issues and/or the use of events for interactive lists, you will find the features and
functions introduced by the new ALV Grid Controlwill make your life a lot simpler.
Granted, the effort to create a classical list for just simple output of data is minimal. But amass a few lists across a
few applications, each created by a different developer, and things get a bit more complicated. The ABAP list
processor lacks standard baseline list handling functions like sorting, filtering, and calculations, so these types of
functions have to be added by hand for each new list. Responsibility for list layout and interface design is also left to
the developer.
This is why you find different schemes for list handling and layout in different applications. Lack of standard, baseline
list processing functions means that developers devise their own methods for common list handling activities such as
headings, sorting, filtering, rendering subtotals, and the like. The result is that end users who work with more than
one application may have to deal with different ways to access these simple list functions based on the developer
who coded the solution.
The ALV Grid Control solves this problem. Its user interface provides a set of generic functions (e.g., sorting, filtering)
for handling tabular data. It also confers the many benefits of controls technology to users, enabling more operations
by mouse, and interaction with other controls, such as drag-anddrop. Developers simply plug the ALV Grid Control
into their applications and the tool takes care of the rest. You do not need to do any further programming to offer
users these functions. How you plug the control into an application is the first thing I will show you in this months
blog. So lets get started!
ALV Grid Control Baseline Functionality
Take a look at the screen shot below; it shows a tab-strip with an ALV Grid Control and its integrated toolbar, which,
thanks to the controls technology, enables mouse-oriented access to a variety of list handling functions.

Columns can be selected and dragged to a different column position. Users can invoke functions that refer to a
selected column (like hide, search, or filter) directly via a context menu. (The selection of columns and rows complies
with the Microsoft standard, which means that users can do things like use the CTRL key to select rows or columns
that are not adjacent.)
Where the ALV Grid Control is placed within a SAP GUI screen is up to you. You can, for example, dock a control to
an arbitrary side of a dynpro. The ABAP Workbench uses this technique in combination with an ALV Grid Control to
dynamically blend in additional information e.g., a global worklist that contains repository objects, or syntax error
messages belonging to the currently shown source code.
Lets take a closer look at the toolbar. See the screen shot below for an overview of the generic functions of the
toolbar.

The user can sort the list by one or more columns, filter entries (e.g., display only data of one day), and calculate
totals and subtotals. Users can determine column order and column length to retrieve needed information in a more
convenient fashion. Developers can allow these settings to be saved in a display variant that can be saved as the
default setting, such that the users preference for settings is loaded before the list is displayed. Some of the
functions made available in the toolbar are there to provide better visualization of lists that either have a lot of
columns or a lot of rows. The Detail function, for example, allows users who are working with a list that has a lot of
columns to view values of a line in a separate pop-up window. For lists that are very long, a user can calculate
subtotals, then collapse all subtotal levels by clicking on the little buttons of the total line. Particular subtotal lines can
be collapsed or expanded, too. Users will also find functions, like the ABC analysis tool, to facilitate the analysis of
data. To print a list, the ALV Grid Control calls the SAP List Viewer. Alternatively, users can export a list to MS Word or
MS Excel. For those who usually work with Excel, the ALV Grid Control offers a function to switch between Grid and
Excel inline display.
Now that you have seen the standard list handling functions that become available to users via the ALV Grid Control,
lets talk about integrating this control with your applications.

Integrating the ALV Grid Control

When you create lists in the classic way, the ABAP list processor is responsible for storing, displaying, and managing
a single list or multiple lists. ABAP statements are used to temporarily store the lists on the application server while
the program is executed, and, with the help of the list processor, display them on a special container screen.
In contrast, the ALV Grid Control uses the SAP Controls Technology for displaying lists. Controls are binary reusable
software components installed on the local PC. (Please see my blog on SAP Controls Technology)
This eliminates the need for the system to access the application server in order to do something like move columns
of a table. Basically, if you use the Controls Technology, specific functions are shifted from the application server
(backend) to the SAP GUI (frontend).
Integrating the ALV Grid Control into a Screen
In order to display the ALV Grid Control (or any control, for that matter) on a screen, you need a container control
instance. A container control is responsible for displaying or arranging one or more controls on the screen. For
integrating a control into a screen, you have a choice of the following five different container control types:
- CL_GUI_CUSTOM_CONTAINER
CL_GUI_DOCKING_CONTAINER
CL_GUI_SPLITTER_CONTAINER
CL_GUI_EASY_SPLITTER_CONTAINER
CL_GUI_DIALOGBOX_CONTAINER
Since these container classes can be combined, there is a tremendous degree of flexibility for placing the ALV Grid
Control on the screen.
The container control is instantiated using the CREATE OBJECT statement, and then linked to an area on the
screen. When a control that is to be displayed is instantiated, you can specify the container control as its parent. This
creates a close connection between these two controls. It is possible to link the control together with its container
control to another screen afterward, which requires that the two screens are at the same pop-up level. This means
that the call level for modal dialog boxes must be the same.
Although there are many methods, events, and attributes defined within the class interface, only one method call is
needed to display a list with the ALV Grid Control. Take a look at the screen shot below..its a cheat sheet for the
definitions and methods needed for displaying a list using the ALV Grid Control.

So once you have generated an instance of the ALV Grid Control, integrated it into a screen, and selected the data
that is to be displayed, this one simple call
is all that you need to provide a list with a set of generic functions.
Generating an instance of the control and integrating it into a screen is not specific to the ALV Grid Control. You do
this the same way you would any control.
What about selecting the data that is to be displayed and passed to the instance together with a description of the
fields? You need to understand that displaying data via the ALV Grid Control requires, at a minimum, that you provide
the following two types of information: the output table and the field catalog.
The output table is an internal table that contains the data that is to be displayed. In most cases, a structure of the
output table already resides in the ABAP Dictionary. When you pass the structure name to the ALV Grid Control, the
field catalog for the description of fields is generated automatically. As you will soon see in upcoming blogs, the field
catalog can be created in a number of ways. You will also see that some of the fields in this catalog must be
specified. The bottom line is that a structure description of the data that is to be displayed must be declared to the
ALV Grid Control either through the field catalog or the corresponding ABAP Dictionary structure.
Lets finish this blog with a code example. I will assume you will create screen 100 and use a custom container to hold
the ALV Grid Control. Here is the code, I will follow with an explanation:
PROGRAM SIMPLE_ALV_CALL.
DATA: OK_CODE LIKE SY-UCOMM,
G_GRID TYPE REF TO CL_GUI_ALV_GRID,
G_CUSTOM_CONTAINER TYPE REF TO CL_GUI_CUSTOM_CONTAINER,
GT_SFLIGHT TYPE TABLE OF SFLIGHT. output table
CALL SCREEN 100.
*************************************************************
MODULE PAI INPUT.
CASE OK_CODE.

WHEN EXIT.
LEAVE PROGRAM.
ENDCASE.
CLEAR OK_CODE.
ENDMODULE.
MODULE PBO OUTPUT.
SET PF-STATUS MAIN100.
* create controls
IF G_CUSTOM_CONTAINER IS INITIAL.
CREATE OBJECT G_CUSTOM_CONTAINER
EXPORTING CONTAINER_NAME = MYCONTAINER.
CREATE OBJECT G_GRID
EXPORTING I_PARENT = G_CUSTOM_CONTAINER.
*
* ALV specific part starts here
*
* data selection
SELECT * FROM SFLIGHT INTO TABLE GT_SFLIGHT.
* display output table in ALV instance
CALL METHOD G_GRID->SET_TABLE_FOR_FIRST_DISPLAY
EXPORTING I_STRUCTURE_NAME = SFLIGHT
CHANGING IT_OUTTAB = GT_SFLIGHT.
ENDIF.
ENDMODULE.
We start by calling SCREEn 100. This calls modules PBO and PAI within its flow logic. At PBO time, we define a
status MAIN100 to leave the program with function code EXIT (this is nothing but classic ABAP dialog programming).
We then create an instance of the Custom Container Control and an instance of the
ALV Grid Control. Note that the latter is connected to the first by parameterI_PARENT and that the container control
is placed on an area that has been defined in the Screen Painter with the name MYCONTAINER. Next we pass ALV
the target data that is to be displayed in a list of the flight model
One last point worth noting is that data selection is well separated from the call to display the data. If this is also the
case for old reports that uses the ABAP list processor at your company, it can be easily converted to a report based
on the ALV Grid Control. The more the data selection is mingled with commands to display the data, the greater the
amount of effort required to convert the old report.
Thats it! Now that the control has been integrated on the screen, you will likely want to configure it to do other cool
things. The key to configuring the ALV Grid Control for your particular application is the structures that are passed by
the application to an ALV Grid instance before or during list display. For some simple extensions of your ALV Grid
instance, you only need to set the right parameter and pass the table or structure by using
method set_table_for_first_display. But this is what we will cover next month

A Guide to the New ALV Grid Control Part 2

Configuring the ALV Grid Control Instance

When we ended the last blog on the ALV Grid Control I promised that we would cover some simple extensions in
this blog. So lets begin..
The key to configuring the ALV Grid Control for your particular application is the structures that are passed by the
application to an ALV Grid instance before or during list display. For some simple extensions of your ALV Grid
instance, you only need to set the right parameter and pass the table or structure by using
methodset_table_for_first_display.
Once the ALV Grid control has been integrated on the screen, you will likely want to configure it to do things like:
- Calculate totals initially
- Hide columns, the toolbar, the grid title, or the column headers
- Add, replace, or hide functions from the toolbar
- React to a double-click on a row to show a detail list
- Interpret values of a column as icons
Like it was stated above, The key to configuring the ALV Grid Control for your particular application is the structures
that are passed by the application to an ALV Grid Control instance. Below is a list of the structures that can be
passed.

Of the seven structure/tables listed above, the field catalog is the most important one for the ALV Grid Control.
Lets take a look at a specific example. Lets say we want to provide a title to our ALV Grid Control. We also would like
to hide the search capability from the standard toolbar so the user doesnt have that ability.

OK lets grab a code snippet from the previous Blog A Guide to the New ALV Grid Control Part 1. Look at the
bold font lines below.
data: gt_exclude type ui_functions.
data: gs_exclude type ui_func.
data: gs_layout type lvc_s_layo.
gs_exclude = cl_gui_alv_grid=>mc_fc_find.
append gs_exclude to gt_exclude.
gs_layout-grid_title = 'My Grid Title'.
CALL METHOD G_GRID->SET_TABLE_FOR_FIRST_DISPLAY
EXPORTING I_STRUCTURE_NAME = 'SFLIGHT'
IS_LAYOUT = GS_LAYOUT
IT_TOOLBAR_EXCLUDING = GT_EXCLUDE
CHANGING IT_OUTTAB = GT_SFLIGHT.
The structure gs_exclude of type ui_func is used in the internal table gt_exclude of type ui_functions. The g is for
Global and s and t are for structure and table respectively. The search function is referenced by the class attribute
MC_FC_FIND of class CL_GUI_ALV_GRID. You can hide other standard functions or menu buttons as well by
adding other attributes with prefix MC_FC_ or MC_MB_, respectively.
We added the title to gs_layout-grid_title.
Finally to get these changes to manifest in our ALV Grid Control, we added IS_LAYOUT = GS_LAYOUT and
IT_TOOLBAR_EXCLUDING = GT_EXCLUDE to the call statement for the method
SET_TABLE_FOR_FIRST_DISPLAY
Setting Properties Using the Field Catalog in the ALV Grid Control
As mentioned earlier, the ALV determines the output format of values using the field catalog. If you choose to build
the field catalog manually, you need to know which fields are mandatory.
Listed below are the required fields.

ALV Grid Required Fields

Fortunately, in most cases you can generate the field catalog (semi-)automatically, as I will show you, so you dont
need to fill in these fields.
Generating the Field Catalog for the ALV Grid Control
You have several options for building a field catalog:
1)Automatically through an ABAP Dictionary structure (as in our example above) the ALV Grid Control then uses
this structure to generate the field catalog on its own
2)Manually in your ABAP program (by filling at least the mandatory fields for each entry of our output table)
3)Semi-automatically by combining the first two procedures
In the case of the first option, you use parameter I_STRUCTURE_NAME, and in the latter cases IT_FIELDCATALOG
of method set_table_for_first_display.
Since the last option is the most commonly used, it will be the focus of our discussion. When generating the field
catalog semi-automatically, you combine structure information of the ABAP Dictionary with your own structure
information.
This allows you to modify or add structure descriptions of new fields to the automatically generated field catalog,
which may be helpful for the following scenarios:
- You want to display an ABAP Dictionary table without displaying all possible columns initially (using field NO_OUT,
another field of the field catalog).
- You want to display additional columns containing icons or other information.
To generate a field catalog semi-automatically all you need to do is call function module
LVC_FIELDCATALOG_MERGE and pass the ABAP Dictionary structure of the output table and the internal table for
the field catalog.
The function module generates the field catalog and fills the internal table accordingly.
Please remember to read the rows you want to change, and adapt the fields accordingly. If your output table contains
more fields than are stored in the ABAP Dictionary, you must append one row for each new field to the field catalog.
Again, an example will help clear this up. The code snippet below deals again with a list of the good old flight model.
In the code, column PLANETYPE is hidden and an additional column is used to display icons.
TYPE-POOLS: icon.
[...]
data: begin of outtab occurs 0.
include structure sflight.

data: icon_column(40) type c.

data: end of outtab.
OK, now lets semi-generate the Field Catalog for the ALV Grid Control.
CALL FUNCTION 'LVC_FIELDCATALOG_MERGE'
EXPORTING I_STRUCTURE_NAME = 'SFLIGHT'
CHANGING CT_FIELDCAT = fieldcat.
Now that we have a field catalog, lets modify entry of field catalog for the column PLANETYPE and stop it from
displaying on the ALV Grid Control.
read table fieldcat into wa_fieldcat with key fieldname="PLANETYPE".
if sy-subrc eq 0.
l_index = sy-tabix.
wa_fieldcat-no_out = 'X'.
modify fieldcat from wa_fieldcat index l_index.
endif.
Now lets add an entry to the field catalog titled ICON COLUMN. This is where we would put an ICON. Later in the
code, we will put the delete icon at the end of a data row.
clear wa_fieldcat.
wa_fieldcat-fieldname = 'ICON_COLUMN'.
wa_fieldcat-outputlen = 5.
wa_fieldcat-just = 'C'.
wa_fieldcat-coltext = 'Icons'.
wa_fieldcat-seltext = 'Icon column'.
append wa_fieldcat to fieldcat.
Finally, lets select the data from the table SFLIGHT and add the the delete icon at the end of the row and display the
ALV Grid Control.
SELECT * FROM SFLIGHT INTO table sflight.
loop at sflight into wa_sflight.
move-corresponding wa_sflight to wa_outtab.
wa_outtab-icon_column = ICON_DELETE.
append wa_outtab to outtab.
endloop.
[...]

CALL METHOD GRID1->SET_TABLE_FOR_FIRST_DISPLAY

10

CHANGING it_fieldcatalog = fieldcat

IT_OUTTAB = outtab[].
Some final thoughts..
SAP developed the ALV Grid Control using a continuous naming convention, which helps you to remember structure
or table names:
- LVC_S_XXXX structures
- LVC_T_XXXX tables; for a table there exists a table type and a corresponding line type in the ABAP Dictionary
(e.g., LVC_S_HYPE is a line type for table LVC_T_HYPE)
- I_*, IS_*, or IT_* for import or changing parameters (simple type, structure, or table) of methods
- E_*, ES_*, or ET_* for export parameters (simple type, structure, or table)
In the next blog we will look at adding Application Specific functions like push buttons or context menu that provides
different functions to the ALV Grid Control. We will also examine how we can use Interactive Reporting with the ALV
Grid Control.

A Guide to the New ALV Grid Control Part 3

Integrating Your Own Application-Specific Functions in the ALV Grid Control

When we ended the last blog on the ALV Grid Control I promised that we would cover adding Application Specific
functions like push buttons or context menu that provides different functions to the ALV Grid Control. I also said we
would learn how we can use Interactive Reporting with the ALV Grid Control. So lets get started!!
You can add the following GUI elements to an ALV Grid instance of an SAP ALV Class:

11

- Push buttons and menus in the toolbar

- A context menu that provides different functions, depending on the column and row position.
Adding new GUI elements to an ALV Grid instance is event-controlled and requires experience in ABAP Objects
event handling. There is an event for each element type (toolbar push button, toolbar menu, and context menu). In
the relevant event handler method, you define the properties of an element (such as its menu options) and assign a
function code to each executable function.
Normally, you must register control events both on the application server (for the ABAP Objects run-time system) and
on the front-end. Please note Control events that are not registered at the front-end will be blocked by the Controls
Technology Framework. This is done to reduce communication overhead between the front-end and back-end. (See
my blog on the Control Technology Framework for a better understanding). The ALV Grid Control initially
registers most events on the front end in order to simplify event handling.
Lets take a look at a generic template below. You can cut and paste this as a template for your own functions.
TYPE-POOLS: icon, cntb.
class <cl_event_receiver definition.
public section.
class-methods:
handle_toolbar for event toolbar of cl_gui_alv_grid
importing sender e_object e_interactive,
handle_menu_button for event menu_button of cl_gui_alv_grid
importing sender e_object e_ucomm,
handle_context_menu for event context_menu_request of cl_gui_alv_grid
importing sender e_object,
handle_user_command for event user_command of cl_gui_alv_grid
importing sender e_ucomm.
endclass.

class lcl_event_receiver implementation.

method handle_toolbar.
<Definition of buttons or menu buttons>
endmethod.
method handle_menu_button.
<Definition of menus for defined menu buttons in 'handle_toolbar'>
endmethod.
method handle_context_menu.
<Definition of context sensitive menu>
endmethod.
method handle_user_command.

12

<Query application specific function codes>

endmethod.
endclass.
[...]
MODULE PBO OUTPUT.
IF G_CUSTOM_CONTAINER IS INITIAL.
* register events on backend:
set handler lcl_event_receiver=>handle_toolbar
lcl_event_receiver=>handle_menu_button
lcl_event_receiver=>handle_context_menu
lcl_event_receiver=>handle_user_command
<call method set_table_for_first_display>
ENDIF.
ENDMODULE.
The definable GUI elements are rebuilt each time the corresponding event is triggered. For this purpose, the event
has the E_OBJECT parameter that contains a reference to the toolbar, or the context menu, or the toolbar menus. In
the event handler method, you can then extend or modify these objects accordingly. All application-specific function
codes can then be queried in event USER_COMMAND.
The graphic below illustrates how to define a button and a menu button in the toolbar, and how the standard context
menu can be extended for a new option. Please note that menus of the toolbar as well as the context menu are not
built until the user invokes them. Whereas elements of the toolbar, on the other hand, are usually defined statically
before list display.

13

Here are some helpful points to remember

When defining elements of the toolbar, the field butn_type determines the type of the GUI element. For possible
values, see type pool CNTB.
In the template, the event handler methods are declared as static methods, which means that they belong to all
instances of the ALV Grid Control in one internal session. When one of these events is raised by one instance, you
can identify this instance by using event parameter SENDER, which is passed implicitly with every event.
Now this is great if you need to add your own custom integration. But what if you needed to change the behavior of a
standard function delivered? Well I am glad you asked.
Modifying the ALV Grid Control Standard Functions
The standard functions are not designed for specific applications. So there may be times when you want to tailor a
generic function such as sorting by a specific column for more efficient operation with a specific application.
One way to do this is to hide the standard function you want to modify and then add your own implementation. While
this approach will certainly work, but there is a more elegant way. Follow these 3 easy steps.

14

1. Define an event handler method for event BEFORE_USER_COMMAND. This event is triggered after the user has
selected a function. This means that the ALV Grid Control passes control to the application before the function is
executed. Using event parameter E_UCOMM, you can trap and restrict the function code to just the function you want
to modify.
2. Implement your own code for the function within the event handler method. In this context, you can even call
methods of the ALV Grid Control if you need too.
3. Reset the function code to ensure that the standard function is no longer executed. You can use code similar to the
below:
CALL METHOD <instance of the ALV control>->set_user_command
exporting I_UCOMM = SPACE.
Lets end this blog series with a look at how you can incorporate the interactive reporting method we all have fond
memories of from our classical reporting days into the ALV grid control.
Interactive Reporting and the ALV Grid Control
So far our discussions have dealt with functionality provided using classical interface elements, such as push buttons,
toolbar menus, and the context menu. There are other interaction facilities can be integrated into an ALV Grid
instance. Take a look at the chart below

As far as the method to integrate these facilities is concerned, the double-click and the hyperlink facility obviously
stand out a little bit. To respond to a double-click, you just have to implement an event handler method for event
double_click. Hyperlinks do not need any event handling, because the corresponding action is always the same
open a Web browser to show the destination of a link. The links have to be defined in a table of type LVC_T_HYPE,
which is passed to the ALV Grid instance using method set_table_for_first_display.
The way to designate a facility to all cells of a single column is controlled by the relevant field in the field catalog. In
the case of hotspots and push buttons, you must set this field to X or attribute cl_gui_alv_grid=>mc_style_button,

15

respectively. In the case of hyperlinks and drag-and-drop behaviors, a handle must be provided instead. By using this
handle, the ALV Grid Control relates the cells of that column to a defined hyperlink or drag-and-drop behavior.
But what if your requirement is for just some cells of a column to be depicted as push buttons e.g., only those
where a condition of the other values of the same row is met? For this purpose, the ALV Grid Control offers a concept
that might be complicated at first glance, but as it can be applied for other facilities too, you will surely encounter it
more than once when you work frequently with this tool.
The idea is to extend the output table by a field that shall not be visible to the user, but which holds additional
information for specific columns of the current row in the table. So lets take a look at the code below
DATA: BEGIN OF GT_OUTTAB OCCURS 0.
INCLUDE STRUCTURE <Your ABAP Dictionary structure>.
DATA: CT TYPE LVC_T_STYL. "Table to refer to cells of a row
DATA: END OF GT_OUTTAB.
In the specific case of push buttons, the additional field has the type of a table with line type LVC_S_STYL, the socalled cell table. This structure has two fields style and fieldname to communicate the row or rows which
columns should be displayed as push buttons, follow these steps
1. To assign this property to all columns, just append one line to the cell table where the field style is set to the button
attribute
cl_gui_alv_grid=>mc_style_button.
2. To assign the property to designated columns, append one line in the cell table for each column. Set the field style
to the button attribute and determine the column using field fieldname.
Lastly, the ALV Grid Control has to be notified of the meaning of the new field in the output table. The field stylefname
of the layout structure is used for this purpose (in our example, you must assign CT to this field). As a consequence,
the ALV Grid Control marks this field in the field catalog as a technical field that is not displayed.
The diagram below may better explain. It shows an output table where cells b1 and c1 as well as the entire second
row are displayed as push buttons through the cell table (to keep the diagram simple, I have assumed that the
constant CL_GUI_ALV_GRID=>MC_STYLE_BUTTON has a value 1).

16

The ALV Grid Control supplies a large set of generic list functions. These standard baseline functions obviate the
need for developers to implement the same code over and over again. As a result, the ALV Grid Control is used
throughout the ECC system and list handling is presented in a uniform way to the user. Moreover, the ALV Grid
Control offers developers great opportunities to easily adapt this technology to support application-specific
requirements.

17