Technical Articles
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:
- SET PF-STATUS … EXCLUDING
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.
- SELECTION-SCREEN FUNCTION KEY
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.
ZCL_EUI_MENU
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.
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
Paul
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.
Documention
https://bizhuka.github.io/eui/zcl_eui_menu/1
Code
https://github.com/bizhuka/eui/blob/master/src/zcl_eui_menu.clas.abap
İ 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.
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?
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.
Right, thanks! Example code for doing tests:
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
Paul
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