ALL SAP ABAP PROGRAMMING: SAP ABAP LESSON 34 ALV GRID CONTROL

ALV GRID CONTROL:

This task is performed by the SAP Control Framework.

The R/3 System allows you to create custom controls using ABAP Objects. The application server is the Automation Client, which drives the custom controls (automation server) at the front end.

If custom controls are to be included on the frontend, then the SAPGUI acts as a container for them.
Custom controls can be ActiveX Controls or JavaBeans.

The system has to use a Remote Function Call (RFC) to transfer methods for creating and using a control to the front end.

ABAP objects are used to implement the controls in programs.

An SAP Container can contain other controls (for example, SAP ALV Grid Control, Tree Control, SAP Picture Control, SAP Splitter Control, and so on). It administers these controls logically in one collection and provides a physical area for the display.

Every control exists in a container. Since containers are themselves controls, they can be nested within one another. The container becomes the parent of its control. SAP containers are divided into five groups:
SAP custom container: Displays within an area defined in Screen Painter on screens or sub screens.
Class: CL_GUI_CUSTOM_CONTAINER
SAP dialog box container: Displays in a modeless dialog box or as a full screen. Class:
CL_GUI_DIALOGBOX_CONTAINER

SAP docking container: Displays as docked, resizable sub-window with the option of displaying it as a modeless dialog box. Class: CL_GUI_DOCKING_CONTAINER
SAP splitter container: Displays and groups several controls in one area - that is, splits the area into cells Class: CL_GUI_SPLITTER_CONTAINER
SAP easy splitter container: Displays controls in two cells, which the user can resize using a split bar. Class: CL_GUI_EASY_SPLITTER_CONTAINER.

In the control, you can adjust the column width by dragging, or use the 'Optimum width' function to adjust the column width to the data currently displayed. You can also change the column sequence by selecting a column and dragging it to a new position.

Standard functions are available in the control toolbar. The details display displays the fields in the line on which the cursor is positioned in a modal dialog box.

The sort function in the ALV Control is available for as many columns as required. You can set complex sort criteria and sort columns in either ascending or descending order.

You can use the 'Search' function to search for a string (generic search without *) within a selected area by line or column.

You can use the 'Sum' function to create totals for one or more numeric columns. You can then use the "Subtotals" function to set up control level lists: You can use the 'Subtotal' function to structure control level lists: select the columns (non-numeric columns only) that you want to use and the corresponding control level totals are displayed.

For 'Print' and 'Download' the whole list is always processed, not just the sections displayed on the screen.

You can define display variants to meet your own specific requirements. For information on saving variants, see 'Advanced Techniques'.

The ALV grid control is a generic tool for displaying lists in screens. The control offers standard functions such as sorting by any column, adding numeric columns, and fixed lead columns .

Data collection is performed in the program (with SELECT statements, for example) or by using a logical database. The data records are saved in an internal table and passed on to the ALV control along with a field description.

The field description contains information about the characteristics of each column, such as the column header and output length. This information can defined either globally in the Dictionary (structure in the Dictionary) or in the field catalog in the program itself. You can also merge both techniques.

The ALV link is a standard function of Query and QuickViewer. If multiline queries or Quick View lists have been defined, they will automatically be compressed to a single line and output in the ALV control as a long, single line list.

Use Screen Painter to create a sub screen container for the ALV grid control. The control requires an area where it can be displayed in the screen. You have to create a container control that determines this area.

Use the corresponding icon in the Screen Painter layout to create the container control. The size of area "MY_CONTROL_AREA" determines the subsequent size of the ALV control.

The valid GUI status must be set at the PBO event in the flow logic of the ALV subscreen container.
The OK_CODE processing for the cancel functions must be programmed at the PAI event.

The reference variables for the custom container and the ALV grid control must be declared.

To create reference variables, use ABAP statement TYPE REF TO .

The global classes you need to do this are called cl_gui_custom_container (for the custom container control) and cl_gui_alv_grid (for the ALV grid control).

The global classes are defined in the Class Builder. You can use the Class Builder to display information for the methods, their parameters, exceptions, and so on.

Use ABAP statement CREATE OBJECT to create the objects for the container and the ALV control. Objects Are instances of a class.

When an object is created (CREATE), method CONSTRUCTOR of the corresponding class is executed. The parameters of method CONSTRUCTOR determine which parameters have to be supplied with data when the object is created. In the above example, object alv_grid is given the name of the container control (g_custom_container) in exporting parameter i_parent, which links the two controls. For information on which parameters method CONSTRUCTOR possesses and which of these parameters are required, see the Class Builder.

Objects should only be created once during the program. To ensure that this is the case, enclose the CREATE OBJECT statement(s) in an IF IS INITIAL. ... ENDIF clause. The objects must be generated before the control is displayed for the first time - that is, during the PBO event of the ALV subscreen container.

To display the requested dataset in the ALV control, the data must be passed on to the control as an internal table, and a field description must exist indicating the order in which the columns will be output.

In the simplest case, the field description can use a structure from the Dictionary. The Dictionary also determines the technical field attributes like type and length, as well as the semantic attributes like short and long texts. The ALV control uses this information to determine the column widths and headers. The column sequence is determined by the field sequence in the structure.

If no suitable structure is active in the Dictionary, or you want to output internal program fields in the control, then you will have to define information like the output length and column header in the field catalog.

In a typical program run, the dataset is read first (SELECT ....), the internal table is filled with the data to display (... INTO TABLE ...), and ABAP statement CALL SCREEN is then used to call the ALV sub screen container.

The data transfer to the ALV control takes place during the call of method
set_table_for_first_display from class cl_gui_alv_grid. The method call must be programmed at the PBO event of the ALV subscreen container.

The name of the Dictionary structure that supplies the field description is specified in exporting parameter i_structure_name. The name of the internal table that contains the data records to display is specified in changing parameter it_outtab.

The field description for the ALV control can be ta ken from an active Dictionary structure (fully automatic), by passing a field catalog (manual), or through a mixture of the two options (merge).

The field catalog is in internal table with type lvc_t_fcat. This type is defined globally in the Dictionary.

Each line in the field catalog table corresponds to a column in the ALV control.

The field characteristics (= column characteristics) are defined in the field catalog. The field catalog is in internal table with type lvc_t_fcat. Each line that is explicitly described in the ALV control corresponds to a column in the field catalog table.

The link to the data records to output that are saved in internal table is established through field name . This name must be specified in column "fieldname" in the field catalog.

This field can be classified through a Dictionary reference (ref_table and ref_field) or by specifying an ABAP data type (inttype).

Column headers and field names in the detail view of an ALV control line can be determined in the field catalog in coltext and seltext, respectively.

The position of a field during output can be determined with col_pos in the field catalog.

If you want to hide a column, fill field no_out with an "X" in the field catalog. Hidden fields can be displayed again in a user display variant.

Icons can be displayed in the ALV control. If you want a column to be interpreted as an icon, then the icon name must be known to the program (include .) and icon = "X" must be specified for this column in the field catalog.

The above example shows a semi-automatic field description: Part of the field description comes from the Dictionary structure (sflight), while another part is explicitly defined in the field catalog (gt_fieldcat).

The field catalog (internal table) is filled in the program and is passed on together with the name of the Dictionary structure during the method call. The information is merged accordingly in method set_table_for_first_display.

For a user to save display variants, parameters is_variant and i_save must be passed on during method call set_table_for_first_screen. To assign display variants uniquely to a program, at least the program name must be supplied in the transferred structure (gs_variant).

Program names can be up to 30 characters long.

If you only pass on the current parameters for is_variant, then existing variants can be loaded, but no new ones can be saved. If you use parameter i_save, you must pass on a variant structure with is_variant.

I_SAVE = SPACE No variants can be saved.

I_SAVE = 'U' The user can only save user-specific variants.

I_SAVE = 'X' The user can only save general (shared) variants.

I_SAVE = 'A' The user can save both user-specific and general (shared) variants.

You can use parameter is_layout of method set_table_for_first_display, for example, to define the header in the ALV control and the detail display.

To do this, define a query area in the program in accordance with Dictionary structure lvc_s_layo, and pass on the text to display in field -grid_title or -detailtitl.

If you want to create print lists with zebra stripes, set field -zebra to "X". You can display a print preview for print lists by requesting standard function "Print".

All parameters of method SET_TABLE_FOR_FIRST_DISPLAY from global class

CL_GUI_ALV_GRID are defined in the Class Builder.

Events are defined in global class cl_gui_alv_grid; you can use these events to implement user interaction within the program. To respond to a double -click on a table line, you must respond to event DOUBLE_CLICK.

You receive control in the program, allowing you to implement interactive reporting - such as a full screen details list. The events for cl_gui_alv_grid are located in the Class Builder.

To define an implement a local class in the program, you use a handler method. In this handler method, you program the functionality to trigger by a double -click in the output table.

To activate a handler method at runtime, a class or an object from that class registers itself with an event using command SET HANDLER. The names of the IMPORTING parameters in the handler method correspond to the names of the EXPORTING parameters of the related event.

In the above example, the local class is LCL_ILS and the handler method is ON_DBLCLICK. An object - ALV_DBLCLICK - is created and registers itself for event DOUBLE_CLICK.

You can query parameter e_row-index to determine which output line was requested by the double -click. This parameter corresponds to the line number of the output table (internal table with the data records to output). If you need information for the selected line, you have to read it with READ TABLE itab INDEX e_row-index.

This subsequent read in the output table generally corresponds to the HIDE area in conventional reporting. You first have to make sure that the user has double -clicked a line in the output table (similar to the valid line selection with the HIDE technique).

A field group can contain global data objects, but not data objects that have been defined locally in a subroutine or function module.

You can use INSERT to specify both fields and field symbols. This makes it possible to dynamically insert a data object referred to by a field symbol into a field group at runtime. Any field symbols that have not been assigned are ignored, which means no new field is inserted into the field group.

The EXTRACT statement writes all the fields of a field group as one record to a sequential dataset (transport takes place with similarly named fields). If a HEADER field group is defined, then its fields are placed ahead of each record as sort keys. You can then sort the dataset with SORT and process it with LOOP ...ENDLOOP. In this case, no further EXTRACT is possible.

The INSERT statement is not a declarative statement: This means field groups can also be expanded in the program flow section.

As soon as the first dataset of a field group has been extracted with EXTRACT, that field group can no longer be expanded with INSERT. In particular, the HEADER field group cannot be expanded after the first EXTRACT (regardless of the field group).

When the GET events are processed, the logical database automatically writes hexadecimal zeros in all the fields of a node when it returns to an upper-level node in the hierarchy. Since the HEADER normally contains sort fields for all field groups, these hexadecimal zeros in the HEADER serve as a type of hierarchy key: The more zeros there are, the further up in the control level hierarchy you go.

The SORT statement sorts the extract dataset in accordance with the defined field sequence in field group HEADER. The addition BY ... sets a new sort key.

Each must be either a field of field group HEADER or a field group that consists only of fields of the field group HEADER. You can use the additions ASCENDING and DESCENDING to determine whether the fields are sorted in ascending (default) or descending order.

Fields containing X'00' in the logical databases are always displayed before all other values during a SORT.

Processing of an extract dataset always takes places within a LOOP. The contents of the extract dataset field are placed in program fields with the same names.

The group change always involves the fields of the HEADER. Single record processing for extract datasets is performed using language element AT ( = field group).

CNT() is not a statement, but instead a field that is automatically create d and filled when is a non-numeric field from field group HEADER and is part of the sort key. At the end of the group, CNT() contains the number of different values that the field recorded in this group level.

SUM() is not a statement, but instead a field that is automatically created and filled when is a numeric field of an extract dataset. At the end of the group, SUM() contains the control total of field .

CUM and CNT are only available at the end of the group level or at AT LAST.

Single record processing for extract datasets AT WITH is only performed when field group is immediately followed by field group in the temporary dataset.

Loops over an extract dataset cannot be nested. However, several contiguous loops are permitted.

The sequence of the control level changes within the LOOP must correspond to the sort sequence.

Totals can only be calculated within control footer processing.

Extracts allow only appends (EXTRACT), sorting (SORT) and sequential processing (LOOP).

Once a SORT or LOOP has occurred, the intermediate dataset is frozen and cannot be expanded with EXTRACT. Operations that insert into or delete from EXTRACT datasets are not supported.

Extracts allow for several record types (FIELD-GROUPS) with fields that can be set dynamically (INSERT is not a declarative statement!). Internal tables have a single, statically-defined line type.

Internal tables use the sequence of table fields according to the declaration for the hierarchy of the control leve l. The control level structure for internal tables is therefore static, and is independent of which criteria were used to sort the internal table.

Extracts do not depend on the field sequence for control level processing: a re-sort or a completely different control level process can take place. The control level structure for extract datasets is therefore dynamic. It corresponds exactly to the sort key of the extract dataset. The sort key is the sequence of fields from the field group HEADER, and is used to sort the extract dataset.

Extracts rely on the compiler to determine which combinations of group levels and a cumulating field the control level totals desire. The desired control level totals are determined by the processing of LOOP ... ENDLOOP blocks. Internal tables build the control level total with the SUM statement.