
Continuing the introduction into the BUS-Screen Framework, I will describe the basis for message handling.
IMPORTANT: First, please make sure you've read and understood my previous BUS-related blog post: http://scn.sap.com/community/abap/user-interface-development/blog/2015/03/24/bus-screen-framework--a...
In order to demonstrate how messages are handle using BUS-Screen Framework, we will create a dummy input field in our previously defined main screen (2000). We will check the value of this field and throw a message.
Notice the input field name corresponds to a public static attribute in our demo class. Therefore, we also have to define it there:
CLASS lcl_demo_main_screen DEFINITION
INHERITING FROM cl_bus_abstract_main_screen
FINAL.
PUBLIC SECTION.
" Screen fields are static as all screens are instantiated as Singletons
CLASS-DATA cv_field TYPE char10.
* ...
NOTE: Except control declarations (which are not supported in OO-context), all field bindings can and should be defined as public static attributes in their corresponding wrapper class.
In order to check the attribute value and throw a message, we will add an extra WHEN section in our previously defined HANDLE_PAI method.
METHOD handle_pai.
* ...
DATA lo_message TYPE REF TO cl_bus_message.
DATA lv_message TYPE string ##needed.
* ...
CASE iv_function_code.
WHEN gc_function_code_enter.
IF cv_field NE 'ABC123'.
MESSAGE e100(sap_guidelines) INTO lv_message.
" Using a dummy statement MESSAGE ... INTO ... can be helpful
" when accessing the 'Where-Used' functionality in a message class.
*
CREATE OBJECT lo_message
EXPORTING
* is_message = ...
" Optional: MOVE-CORRESPONDING sy TO ls_message, where ls_message is of type symsg.
iv_cursor_screen = me
iv_highlighted_field = 'CL_DEMO_MAIN_SCREEN=>CV_FIELD'.
" Passing the SY-MSG structure to the BUS message instance is optional.
"If empty, syst fields will be automatically used. Alternatively, the ls_message structure can be filled manually.
* ...
The idea is to let the PAI processing continue even if faulty and only display messages in the PBO section.
For the actual message display, we will redefine method PAI_END in the public section of our local demo class.
METHODS pbo_end REDEFINITION.
NOTE: Although the message-relevant functions are available in the CL_BUS_ABSTRACT_SCREEN base class, the actual display of the message should only be performed (ONCE) in the current instance of CL_BUS_ABSTRACT_MAIN_SCREEN.
METHOD pbo_end.
super->pbo_end( ).
*
" Attribute gt_messages is filled automatically by passing reference 'me'
" as parameter iv_cursor_screen in the CONSTRUCTOR of CL_BUS_MESSAGE.
cl_bus_message=>get_most_severe_message(
EXPORTING it_message = gt_messages
IMPORTING ev_message = gv_message ).
*
IF gv_message IS BOUND.
MESSAGE ID gv_message->gs_message-msgid TYPE 'S'
NUMBER gv_message->gs_message-msgno
TYPE gv_message->gs_message-msgv1
gv_message->gs_message-msgv2
gv_message->gs_message-msgv3
gv_message->gs_message-msgv4
DISPLAY LIKE gv_message->gs_message-msgty.
"
*
" After displaying the message, the buffer should be refreshed.
clear_messages( ).
ENDIF.
ENDMETHOD.
NOTE: It is important to understand the order in which PBO and PAI methods are called, and how to redefine them in your classes.
In the next blog post, I will show you how to implement the logic of a tabstrip and sub screens using the BUS-Screen Framework.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
2 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |