Skip to Content
Technical Articles
Author's profile photo Birzhan Moldabayev

Dynamic way to add a button where you want

How often developers use buttons in user interfaces? Is it easy by comparison with Web dynpro & Fiori elements to create a simple one in SAP gui? Let’s refresh in our memory well known ways of making them. In classical (may I say old-fashioned?) ABAP there are several ways to make buttons dynamically:


Usually if there are just few of actions associated with buttons ABAP-ers could create all of them and exclude unnecessary ones. Also we have ability to create several PF-STATUS and choose the desired by condition. It could be very helpful if you have a PF-STATUS based on standard ALV and most of the positions in it are already occupied by standard actions like ‘Select All’ ‘Unselect all’ etc. That’s why personally I prefer to create a ALV toolbar instead of PF-STATUS.


At selection screens we have ability to create up to 4 buttons at a time. Icons & texts could be set programmatically. But if use LDB like PNPCE or PCH there are would no vacant place for new button.

  • SELECTION-SCREEN – PUSHBUTTON (or ordinary button in the screen painter)

Is very similar to a previously described FUNCTION KEY approach with additional advantage to place them anywhere you want.

What all 3 approach have in common? I think you already noticed, they have explicit ABAP language declarations and you cannot create them by “pure” code.

You could disagree with me, but all listed above ways of creating buttons have some kind of restrictions. Since special language constructions are usually static by their essence and they are tightly coupled with the screens they belong to.

Loose coupling in the other hand can bring more flexibility and allows us to create universal UI for different purpose. And in SAP gui there is an good example of that kind of flexible design.


GOS buttons created by CL_GUI_TOOLBAR

Usually well known (from 7.00 I guess) GOS menu were used for file attachments. But wait could we use CL_GUI_GOS_CONTAINER class for our own purpose? I think we could. Why not? And made small class for this goal.



The class can create buttons like this



or hierarchical menus like this


as an ordinary gos menus.


for event handling you have to pass an object to ZCL_EUI_MENU constructor. And all methods


‘for event FUNCTION_SELECTED OF cl_gui_toolbar’ will be triggered in it.


A dynamic toolbar like this would be probably helpful just in a certain circumstances. Full pf-status or dynamically changed menus could be good cases to try this class. But I hope that standard CL_GUI_GOS_CONTAINER class (just recently discovered by me) would give you food for thought about casual things like buttons.


Additional information about the wrapper class available here.

If you have an ALV & don’t like PF-STATUS maybe ALV toolbar will be your choice.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Paul Hardy
      Paul Hardy

      So what you are saying is that it is possible to add custom buttons to the right of the GOS box? Can you provide some more code as to how this actually works, maybe on GitHub?

      The GOS box usually only appears on screens showing detail of master data objects like customers. Is you idea to also show it on ALV reports so you can add extra buttons to the right of that as well?

      Cheersy Cheersy


      Author's profile photo Birzhan Moldabayev
      Birzhan Moldabayev
      Blog Post Author

      You can create several instances of CL_GUI_GOS_CONTAINER and add any gui control in it (didn't check it though). They will be displayed consequently.





      İ used this class a couple of times when almost all buttons in pf-status were occupied & for good alternative to function key in selection screen.

      Also by default in option utility there is a special menu which displays info & data of an option.

      Author's profile photo Sandra Rossi
      Sandra Rossi

      If I remember well, there was a maximum width for one "GOS container" (i.e. the container at the left of the title). I didn't know that several ones could be instantiated. Do you know if this maximum width applies to one or to all GOS containers?

      Author's profile photo Birzhan Moldabayev
      Birzhan Moldabayev
      Blog Post Author

      You can specify the width of gos containers separately.

      Usually I test appearance in several languages since if there is no enough space for inner control the container will display scrollbars.

      Author's profile photo Sandra Rossi
      Sandra Rossi

      Right, thanks! Example code for doing tests:

      DATA go_container TYPE REF TO cl_gui_gos_container.
      DATA go_toolbar TYPE REF TO cl_gui_toolbar.
      PARAMETERS dummy TYPE string.
        IF go_container IS NOT BOUND.
          CREATE OBJECT go_container
              width  = 2000
              OTHERS = 1.
          CREATE OBJECT go_toolbar
              parent       = go_container
              display_mode = cl_gui_toolbar=>m_mode_horizontal.
          DATA(lt_data) = VALUE ttb_button(
              FOR i = 1 WHILE i <= 20
              ( function = |A{ i }| icon = icon_okay disabled = abap_false butn_type = cntb_btype_group text = |very long text { i }| quickinfo = '' checked = abap_false ) ).
          CALL METHOD go_toolbar->add_button_group
              data_table = lt_data
              dp_error   = 1.
      Author's profile photo Paul Hardy
      Paul Hardy

      I notice in the example code (eui/zcl_eui_menu.clas.abap at master · bizhuka/eui · GitHub)

      you have IF SY-ONCOM <> 'V'.

      What is SY-ONCOM used for?

      In any event this is looking really good. Having a PF-STATUS fill up is all too horribly common. Far better to be able to be able to add buttons dynamically.

      And despite the official position SAP GUI is going to be with us for a very long time.

      Cheersy Cheers




      Author's profile photo Birzhan Moldabayev
      Birzhan Moldabayev
      Blog Post Author

      honestly speaking I forgot what does it mean (copied the from standard gos menu code)



      there are some additional checks for testing in background job, web -dynpro mode etc


      Also the  ZCL_EUI_MENU could be useful in standard screens. For example if there is no menu nor screen exists. but in that case you have to explicitly pass IV_CHECK_TCODE = abap_false



      for safety reason by default the menu will be displayed only in Z* & Y* transactions