ABAP Quick - Classes and Dynpros
How do you best use local classes and screens with each other? And does the whole thing actually make sense?
How exactly do classes and screens work together? And can you actually link them meaningfully? Today we show you a solution how it can work.
Local class
We define the local class according to our requirements. We take the PBO and PAI of screen 2000 into scope and create a public attribute for the screen data. In this case, it is important that the visibility of the attributes on the screen is public, otherwise they cannot be accessed from our main program.
Here is the example class, how the implementation looks for our example:
CLASS lcl_prog DEFINITION FINAL.
PUBLIC SECTION.
TYPES:
BEGIN OF ts_screen,
bukrs TYPE t001-bukrs,
text TYPE text50,
END OF ts_screen.
DATA:
ms_screen TYPE ts_screen.
METHODS:
start,
pbo_2000,
pai_2000.
PRIVATE SECTION.
ENDCLASS.
CLASS lcl_prog IMPLEMENTATION.
METHOD start.
ms_screen-bukrs = '0815'.
ms_screen-text = 'A random text'.
CALL SCREEN 2000.
ENDMETHOD.
METHOD pbo_2000.
SET PF-STATUS '2000'.
SET TITLEBAR '2000'.
ENDMETHOD.
METHOD pai_2000.
CASE sy-ucomm.
WHEN 'BACK' OR 'LEAVE' OR 'EXIT'.
LEAVE PROGRAM.
ENDCASE.
ENDMETHOD.
ENDCLASS.
Dynpro
When defining the screen, we can then directly access the attributes via the global instance, read and store data in it. When storing the fields, it is only important to ensure that only public attributes of the instance can be used.
The disadvantage of this method is that the field properties cannot be used from the context of the variable, as with a global variable that was defined using TABLES. Another advantage is the decoupling from the main program and the global data. In the end, you will probably choose a hybrid approach for your solution.
Connection
The class is connected via the classic modules for PBO and PAI, but here you only need to call the methods and can implement the rest of the logic in the class, as in the example class above.
MODULE pbo_2000 OUTPUT.
go_app->pbo_2000( ).
ENDMODULE.
MODULE pai_2000 INPUT.
go_app->pai_2000( ).
ENDMODULE.
Result
After starting the report you will get the following result. The fields were filled before the screen was opened and are displayed correctly and can also be changed. The display of the menu and the processing of the user-command also work as desired.
Conclusion
Working with screens is now not a problem for you in the world of classes. You just have to make it clear to yourself at what time which methods are called and where your data is used. A hybrid approach with the definition of global structures via TABLES and the transfer of data to the class is recommended for the implementation of complex applications.
