Skip to Content

BUS screen framework: Table Controls

I have a screen with four subscreens, each of them must carry a table control. What I have to do to implement the table control? The same as I have to do in "old school"-screens, like:

LOOP AT ....

INTO ....

WITH CONTROL ....

....

ENDLOOP.

in PBO and PAI? Or are there any generic methods I can call?

Edit: Additional Question

I do have a table control, let's say it's linetype is MARA.

If I code:

LOOP AT lcl_subscreen=>table_control

INTO lcl_subscreen=>table_control_row

WITH CONTROL tc_mara

CURSOR tc_mara-current_line.

ENDLOOP.

the program does not work. Of course, there is a local class with:

CLASS-DATA:

  table_control TYPE STANDARD TABLE OF mara,

   table_control_row TYPE MARA.

If I change the loop to:

LOOP AT table_control

INTO table_control_row

WITH CONTROL tc_mara

CURSOR tc_mara-current_line.

ENDLOOP.

by using global data in TOP Include

DATA:

  table_control TYPE STANDARD TABLE OF mara,

  table_control_row TYPE MARA.

it works. But I don't want to use global data, I want to use class attributes.

What I am doing wrong? 😢

Message was edited by: Ralf Wenzel for entering additional question

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • avatar image
    Former Member
    Nov 03, 2015 at 04:07 AM

    Hi Ralf,

    The problem in a similar case of mine was that the value to the class attribute I tried to read in the PBO was set in my PBO.. which is somehow too late for the screen-manager.

    Is you lcl_subscreen already defined or do you define/create it in the same PBO? Try to set the value in the bus_screen_create for example, or use a constant or use the 'value' attribute in the definition, than it probably works out.

    Cheers,

    PhiL

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      It took the administrator a couple of days to release my post (moderated), in the meantime, I have successfully implemented one table control on the BUS Framework. Afterwards, I removed them again, because I didn't liked the way it was implemented. the global table control and that logic of moving data back and forth is not what I wanted in my first real Bus Framework Application. I went with a regular CL_GUI_ALV instead. Maybe you also want to reconsider if you really need the table control for it.

      PROCESS BEFORE OUTPUT.

         MODULE dynpro_pbo.

         Module tc_round_x_init.

         LOOP AT lcl_screen_100=>x_tab
            INTO lcl_screen_100=>x
          WITH CONTROL tc_round_x
                CURSOR tc_round_x-current_line.
         ENDLOOP.

      PROCESS AFTER INPUT.

         LOOP AT lcl_screen_100=>x_tab.
           CHAIN.
             FIELD  lcl_screen_100=>x-upper_limit.
             FIELD  lcl_screen_100=>x-waerk.
             FIELD  lcl_screen_100=>x-roundingprocedure.
             FIELD  lcl_screen_100=>x-decimals.
             MODULE tc_round_x_modify ON CHAIN-REQUEST.
           ENDCHAIN.
         ENDLOOP.
         MODULE dynpro_pai.


      whereby:


      MODULE tc_round_x_init OUTPUT.
         DATA: ls_settings_steps     LIKE LINE OF  lcl_application=>edirect_settings_x_tab. "(table of persistent objects)
         DATA: ls_zedir_rounding_x   TYPE          zedir_rounding_x.

         REFRESH lcl_screen_100=>x_tab. "We always refresh to be consistent in what we see and what we have in the persistent class.

         LOOP AT lcl_application=>edirect_settings_x_tab INTO ls_settings_steps.
           ls_zedir_rounding_x-upper_limit       = ls_settings_steps->get_upper_limit( ).
           ls_zedir_rounding_x-waerk             = ls_settings_steps->get_waerk( ).
           ls_zedir_rounding_x-roundingprocedure = ls_settings_steps->get_roundingprocedure( ).
           ls_zedir_rounding_x-decimals          = ls_settings_steps->get_decimals( ).
           APPEND ls_zedir_rounding_x TO lcl_screen_100=>x_tab.
         ENDLOOP.

         SORT lcl_screen_100=>x_tab BY upper_limit ASCENDING.

         tc_round_x-lines = 0. "always enable all rows for input

      ENDMODULE.                    "tc_round_x_max OUTPUT


      MODULE tc_round_x_modify INPUT.
         DATA: lo_setting_step LIKE LINE OF lcl_application=>edirect_settings_x_tab.
       
         TRY.
             lo_setting_step = zca_pers_zedir_rounding_x=>agent->get_persistent(
                                     i_specialroundid = lcl_application=>edirect_settings->get_specialroundid( )
                                     i_upper_limit    = lcl_screen_100=>x-upper_limit
             ).

           CATCH cx_os_object_not_found.

             lo_setting_step = zca_pers_zedir_rounding_x=>agent->create_persistent(
                                     i_specialroundid = lcl_application=>edirect_settings->get_specialroundid( )
                                     i_upper_limit    = lcl_screen_100=>x-upper_limit
             ).

         ENDTRY.

         lo_setting_step->set_decimals( lcl_screen_100=>x-decimals ).
         lo_setting_step->set_roundingprocedure( lcl_screen_100=>x-roundingprocedure ).
         lo_setting_step->set_waerk( lcl_application=>edirect_settings->get_waerk( ) ).
         lo_setting_step->set_aenam( sy-uname ).
         lo_setting_step->set_aedat( sy-datum ).

         APPEND lo_setting_step TO lcl_application=>edirect_settings_x_tab.

      ENDMODULE.                    "TC_ROUND_X_MODIFY INPUT
      *--------------------------------------------------------------------

  • Nov 04, 2015 at 05:08 PM

    Does really NOONE work with BUS Screen Framework? *grrr

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 05, 2015 at 12:42 PM

    it works. But I don't want to use global data, I want to use class attributes.

    But from online help Dynpro Fields (7.40)

    After PBO and before the screen is sent, there is a data transport of global data objects for the respective ABAP program to dynpro fields of the same name. After a user action on the screen, and before or during PAI editing, the data transport takes place in the reverse order.

    and

    When dynpro fields are defined with reference to flat structures in ABAP Dictionary, the global data objects with the same name of the ABAP program must be declared with the statement TABLES as interface work area. Otherwise, there will be no data transport.

    So I fear you don't have (yet ?) the choice?

    So far my classes use some function group/module pool to communicate with classic screen dynpro 😔

    Add comment
    10|10000 characters needed characters exceeded

    • You could try some

      LOOP with control tc_mara.

        lcl_subscreen=>set_record( tc_mara-current_line ).

      ENDLOOP.

      With table control displayed fields defined as a lcl_subscreen=>record-field ?

      Regards,

      Raymond