Code: Alles auswählen.
METHOD create_alv.
FIELD-SYMBOLS: <ft_table> TYPE STANDARD TABLE.
ASSIGN _rt_table->* TO <ft_table>.
IF <ft_table> IS ASSIGNED AND <ft_table> IS NOT INITIAL.
TRY.
CALL METHOD cl_salv_table=>factory
IMPORTING
r_salv_table = _alv
CHANGING
t_table = <ft_table>.
CATCH cx_salv_msg.
ENDTRY.
ENDIF.
ENDMETHOD.
Code: Alles auswählen.
_r_functions = _alv->get_functions( ).
_r_functions->set_all( abap_true ).
TRY.
_r_functions->add_function( name = 'TEST'
tooltip = 'TEST'
* text = 'test'
position = if_salv_c_function_position=>right_of_salv_functions ).
CATCH cx_salv_method_not_supported INTO DATA(lr_error).
ENDTRY.
Ich habe es jetzt doch außerhalb der Klasse gemacht, weils für mich unkomplizierter war.a-dead-trousers hat geschrieben: ↑11.11.2022 17:30Die "dynamische" Variante der Funktionscodes verwendet eine CL_GUI_TOOLBAR. Da kann man beliebige Funktionen hinzufügen. Damit man diese Variante von SALV bekommt, benötigt man ein Dynpro mit einem Custom-Container und im Aufruf der Factory-Methode muss man entweder dessen Namen angeben oder eine bereits darauf initialisierte Container-Instanz.
Die "statische" Variante der Funktionscodes verwendet einen GUI-Status. Dabei übernimmt das SALV-Framework alles, von der Bereitstellung eines Dynpros bis hin zur Funktionscodeverabeitung des GUI-Status. Der Nachteil ist, dass man hier nicht so ohne weiteres neue Funktionscodes hinzufügen kann. Man müsste sich den Standard-GUI-Status des SALV kopieren und dann um eigene Funktionscodes erweitern. Diesen neuen GUI-Status kann man dem SALV dann mit der Methode SET_SCREEN_STATUS anweisen zu verwenden.