OOALV problem with input chekcs

Former Member · ‎2007 Nov 29

HI

In my object I have following functionality :

1. A simple OOALV display with two fields input enabled.

2. Then user will enter data in input enabled fields and will press 'EXECUTE' pushbutton added on OOALV toolbar.

3. The newly added data in those two fields will be authorized first and then a BAPI will be called to perform an action.

4. If that authorization fails then an error message will be displayed and user can modify the corresponding entry such as to satisfy input checks and then user will again press "EXECUTE" pushbutton on OOALV toolbar and corresponding action will be performed as mentioned earlier.

So, the query in my program is that, when I enter wrong values in those input enabled fields an error is displayed as required but when i correct those values and press on "EXECUTE" the control goes out of the program.

Thanks in advance !

former_member199581 · ‎2007 Dec 04

Can you post a snippet of your code?

Focus on the piece of code that performs the checks and on PAI module of the screen.

Former Member · ‎2007 Dec 05

1) in the ON TOOLBAR method in your class have something like this

method ON_TOOLBAR.

type-pools icon.

CLEAR ls_toolbar.

MOVE 0 TO ls_toolbar-butn_type.

MOVE 'PROC' TO ls_toolbar-function.

MOVE space TO ls_toolbar-disabled.

MOVE icon_businav_process TO ls_toolbar-icon.

MOVE 'Process.' TO ls_toolbar-quickinfo.

MOVE 'PROC' TO ls_toolbar-text.

APPEND ls_toolbar TO e_object->mt_toolbar.

.

...

endmethod.

2) in the ON_USER_COMMAND method code something like this

method ON_USER_COMMAND.

FOR EVENT before_user_command OF cl_gui_alv_grid
IMPORTING
e_ucomm
sender.

CASE e_ucomm.

WHEN 'EXIT'.

LEAVE PROGRAM.

WHEN 'PROC'.

CALL METHOD me->process.

ENDCASE.

...

endmethod.

If you have already defined a class with SE24 you don't need the commented bits.

3) Now for your processing code

method PROCESS.

PERFORM process IN PROGRAM (caller) IF FOUND.

...

endmethod.

Then simply do what you want in the form PROCESS in your application code.

Form process.

code some stuff

endform.

You need to pass the name of your calling program to your class

something like this

IF z_object IS INITIAL.

CREATE object Z_OBJECT

exporting Z_OBJECT = Z_OBJECT.

CALL METHOD z_object->build_dynamic_structures

EXPORTING

my_line = my_line

calling_program = invoker

IMPORTING

dy_table = dy_table

CHANGING

it_fldcat = it_fldcat.

ENDIF.

my z_object refrers to my alv handling class zcl_alv_test.

If you have a status set up (SE41) then the PAI can be something like this

MODULE user_command_0100 INPUT.

CASE sy-ucomm.

WHEN 'BACK'.

LEAVE PROGRAM.

WHEN 'EXIT'.

LEAVE PROGRAM.

WHEN 'RETURN'.

LEAVE PROGRAM.

WHEN OTHERS.

ENDCASE.

ENDMODULE.

Now if you want to be really smart you can create a function module to handle the screen so you don't need a separate screen for each ALV program.

This works if you only need a single grid to be displyed in a scrren.

I'm looking at creating a version which handles multiple grids on the screen but I haven't many applications that need this so it might take a while.

I can post the class if you want.

Using this type of approach means you can create very flexible ALV applications extremely quickly using the minimum amont of code.

Here's my FMOD

FUNCTION ZZ_CALL_SCREEN.

*"----

""Local interface:

*" IMPORTING

*" REFERENCE(INVOKER) TYPE SYREPID

*" REFERENCE(MY_LINE) TYPE ANY

*" REFERENCE(I_GRIDTITLE) TYPE LVC_TITLE

*" REFERENCE(I_EDIT) TYPE LVC_EDIT

*" REFERENCE(I_ZEBRA) TYPE LVC_EDIT

*" EXPORTING

*" REFERENCE(DY_TABLE) TYPE REF TO DATA

*" REFERENCE(Z_OBJECT) TYPE REF TO ZCL_ALV_TEST

*"----

*

This function module instantiates a generic
ALV handling class
Builds a dynamic fcat from the structure passed in my_line
Creates a dynmic table using the FCAT created in the class
calls the alv display
Using this approach means that the calling programs
now no longer need a separate screen.
The dynamic table is now filled in the
form POPULATE_DYNAMIC_TABLE
which MUST exist in the calling program.
It is done this way as it is not praticable to have
a completely generic method of filling the dynamic table
as data selection depends on the application - could be via
joins etc etc.

Note that screen 100 and a standard interface (se41) are contained in
the main program of this function module.
screen just has one element a custom container called CCONTAINER1
status (SE41) is just a standard status with BACK EXIT and CANCEL
buttons.
screen logic simply
PROCESS BEFORE OUTPUT.
MODULE STATUS_0100.

*

PROCESS AFTER INPUT.
MODULE USER_COMMAND_0100.

*

*module STATUS_0100 output.

*z_object = <zogzilla>.

call method z_object->display_grid
exporting
g_outtab = <dyn_table>
g_fldcat = it_fldcat
i_gridtitle = w_gridtitle
i_edit = w_edit
i_zebra = w_zebra
changing
it_fldcat = it_fldcat
gt_outtab = <dyn_table>.
set pf-status '001'.
set titlebar '000'.
ENDMODULE.

*MODULE user_command_0100 INPUT.

*

CASE sy-ucomm.
WHEN 'BACK'.
LEAVE PROGRAM.
WHEN 'EXIT'.
LEAVE PROGRAM.
WHEN 'RETURN'.
LEAVE PROGRAM.
WHEN OTHERS.
ENDCASE.

*ENDMODULE.

Function module code
Create instance of the ALV handling class ZCL_ALV_TEST
Build an FCAT based on the structure passes in my_line
create a dynmic table based on the FCAT created
call back to the calling program (invoker) to fill
the dynamic table
call the screen to display tha ALV grid

*

event handling etc all built into the class

IF z_object IS INITIAL.

CREATE object Z_OBJECT

exporting Z_OBJECT = Z_OBJECT.

CALL METHOD z_object->build_dynamic_structures

EXPORTING

my_line = my_line

calling_program = invoker

IMPORTING

dy_table = dy_table

CHANGING

it_fldcat = it_fldcat.

ENDIF.

variable z_object contains the instance of our class zcl_alv_test
we need to keep the value as it needs to be passed to the PBO routine
when screen 100 is called.

assign z_object to <zogzilla>.

*

perform populate_dynamic_itab in program (invoker)

changing dy_table.

As detailed in the comments above this form MUST exist in the calling
program

*

change column headings etc if required - not mandatory

perform name_columns in program (invoker) if found

changing it_fldcat.

now display the grid

ASSIGN dy_table->* TO <dyn_table>.

w_gridtitle = i_gridtitle.

w_edit = i_edit.

w_zebra = i_zebra.

call screen 100.

ENDFUNCTION.

My application program calls it as follows

CALL FUNCTION 'ZZ_CALL_SCREEN'

EXPORTING

invoker = invoker

my_line = <fs>

i_gridtitle = i_gridtitle

i_edit = i_edit

i_zebra = i_zebra

IMPORTING

z_object = z_object

dy_table = dy_table.

In the application program you populate the dynamic table something like this

define your structure / itab before calling the class.

TYPES: BEGIN OF s_elements,

tabname TYPE dd02l-tabname,

tabclass TYPE dd02l-tabclass,

as4user TYPE dd02l-as4user,

as4date TYPE dd02l-as4date,

as4time TYPE dd02l-as4time,

viewed(1) TYPE c.

TYPES: END OF s_elements.

the class returns the fcat and dynamic table.

you fill the dynamic table for example based on the structure above (s_elements)

FORM populate_dynamic_itab CHANGING dy_table.

ASSIGN dy_table->* TO <dyn_table>.

CREATE DATA dy_line LIKE LINE OF <dyn_table>.

ASSIGN dy_line->* TO <dyn_wa>.

SELECT *

FROM dd02l

INTO CORRESPONDING FIELDS OF TABLE <dyn_table>

WHERE tabname LIKE 'ZHR%'.

ENDFORM.

Cheers

jimbo