Im Popup kein SALV_TABLE?
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Moin,
ich sitze scheinbar zu lange am Rechner -- in der Hoffnung, dass das zeitnah einer liest und mir den Tritt in die richtige Richtung geben möge:
Warum wird bei Auswahl von POPUP kein SALV angezeigt?
Gegeben sei ein Screen 0100 und die zwei Status 'TEST' und 'TEST_POPUP', wo nur der Abbrechen-Button mit ABORT belegt ist und dieses Programm:
Ich gehe davon aus, dass ich irgendeine blöde versch$§%.... Kleinigkeit übersehe und möchte das Programm (das hier ist ja nur ein Beispiel, das auf das Problem konzentriert ist) ASAP fertig kriegen.
Ralf
ich sitze scheinbar zu lange am Rechner -- in der Hoffnung, dass das zeitnah einer liest und mir den Tritt in die richtige Richtung geben möge:
Warum wird bei Auswahl von POPUP kein SALV angezeigt?
Gegeben sei ein Screen 0100 und die zwei Status 'TEST' und 'TEST_POPUP', wo nur der Abbrechen-Button mit ABORT belegt ist und dieses Programm:
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Report Z_RW_TEST
*&
*&---------------------------------------------------------------------*
*& Warum wird bei Auswahl von 'POPUP' keine Tabelle angezeigt?
*&---------------------------------------------------------------------*
REPORT z_rw_test.
DATA:
data TYPE STANDARD TABLE OF seocompo,
container TYPE REF TO cl_gui_container,
salv TYPE REF TO cl_salv_table.
PARAMETERS:
normal RADIOBUTTON GROUP con,
popup RADIOBUTTON GROUP con.
CASE abap_true.
WHEN normal.
DATA(custom_container) = NEW cl_gui_custom_container(
container_name = 'CONTAINER'
repid = sy-repid
dynnr = '100'
).
container = custom_container.
WHEN popup.
DATA(popup_container) = NEW cl_gui_custom_container(
container_name = 'CONTAINER'
repid = sy-repid
dynnr = '100'
).
container = popup_container.
WHEN OTHERS.
ENDCASE.
SELECT * FROM seocompo
INTO TABLE data
UP TO 10 ROWS.
cl_salv_table=>factory(
EXPORTING
list_display = if_salv_c_bool_sap=>false
r_container = container
container_name = 'CONTAINER'
IMPORTING
r_salv_table = salv
CHANGING
t_table = data
).
salv->display( ).
IF popup EQ abap_true.
CALL SCREEN 100 STARTING AT 1 1.
ELSE.
CALL SCREEN 100.
ENDIF.
MODULE status_0100 OUTPUT.
IF popup EQ abap_true.
SET PF-STATUS 'TEST_POPUP'.
ELSE.
SET PF-STATUS 'TEST'.
ENDIF.
ENDMODULE.
MODULE user_command_0100 INPUT.
IF sy-ucomm EQ 'ABORT'.
LEAVE PROGRAM.
ENDIF.
ENDMODULE.Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi Ralf,
versuche mal für das Pupup ein eigenes "Modales Dialogfenster" zu benutzen (nicht für beide ein screen 100), ausserdem würde ich das Erzeugen des Containers in die PBOs der Screens verlagern, damit läuft das Beispiel bei mir.
/Edwin
versuche mal für das Pupup ein eigenes "Modales Dialogfenster" zu benutzen (nicht für beide ein screen 100), ausserdem würde ich das Erzeugen des Containers in die PBOs der Screens verlagern, damit läuft das Beispiel bei mir.
Code: Alles auswählen.
DATA:
data TYPE STANDARD TABLE OF seocompo,
container TYPE REF TO cl_gui_container,
salv TYPE REF TO cl_salv_table.
DATA create_container TYPE flag VALUE 'X'.
PARAMETERS:
normal RADIOBUTTON GROUP con,
popup RADIOBUTTON GROUP con.
SELECT * FROM seocompo
INTO TABLE data
UP TO 10 ROWS.
IF popup EQ abap_true.
CALL SCREEN 110 STARTING AT 1 1. "<<<<<< Modales Dialogfenster
* MODULE PBO UND PAI wie 100
*
ELSE.
CALL SCREEN 100.
ENDIF.
MODULE status_0100 OUTPUT.
IF popup EQ abap_true.
SET PF-STATUS 'TEST_POPUP'.
ELSE.
SET PF-STATUS 'TEST'.
ENDIF.
IF create_container = 'X'.
CASE abap_true.
WHEN normal.
DATA(custom_container) = NEW cl_gui_custom_container(
container_name = 'CONTAINER'
repid = sy-repid
dynnr = '100'
).
container = custom_container.
WHEN popup.
DATA(popup_container) = NEW cl_gui_custom_container(
container_name = 'CONTAINER'
repid = sy-repid
dynnr = '0110'
).
container = popup_container.
WHEN OTHERS.
ENDCASE.
cl_salv_table=>factory( EXPORTING list_display = if_salv_c_bool_sap=>false
r_container = container
container_name = 'CONTAINER'
IMPORTING r_salv_table = salv
CHANGING t_table = data ).
salv->display( ).
clear create_container.
ENDIF.
ENDMODULE.
MODULE user_command_0100 INPUT.
IF sy-ucomm EQ 'ABORT'.
LEAVE PROGRAM.
ENDIF.
ENDMODULE.Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Folgende Benutzer bedankten sich beim Autor edwin für den Beitrag:
ralf.wenzel
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Das zweite Dynpro brauchts übrigens nicht - aber man möge mir erklären, warum so viel Zeugs in das PBO muss. Da will ich es nämlich gar nicht haben.
Interessant ist, dass sich das nur aufs Popup auswirkt, sowohl Fullscreen als auch Darstellung im Container oder Docking Container geht problemlos mit meinem Programm - nur Popup nicht.
Ralf
Interessant ist, dass sich das nur aufs Popup auswirkt, sowohl Fullscreen als auch Darstellung im Container oder Docking Container geht problemlos mit meinem Programm - nur Popup nicht.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Weil der Popup-Level aus irgendeinem Grund wichtig ist. Ich habe auch nie verstanden, warum.ralf.wenzel hat geschrieben: ↑27.03.2020 08:14Das zweite Dynpro brauchts übrigens nicht - aber man möge mir erklären, warum so viel Zeugs in das PBO muss. Da will ich es nämlich gar nicht haben.
Interessant ist, dass sich das nur aufs Popup auswirkt, sowohl Fullscreen als auch Darstellung im Container oder Docking Container geht problemlos mit meinem Programm - nur Popup nicht.
Du kannst z.B. auch keinen Container von einem Level in den nächsten umhängen. Es geht, wenn die Container auf gleicher Ebene sind:
https://tricktresor.de/blog/container-umhaengen/
Aber leider nicht von einem Container auf Ebene Screen0 auf den ersten Popup-Level Screen1. Das wollte ich mal haben, um in einem Dialog einzelne Container abdocken zu können. Das geht aber nur, indem man das Control zerstört und wieder komplett neu aufbaut.
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Muss es denn ein "eigenes" Dynpro sein?
cl_salv_table hat doch von sich aus eine "Popup"-Funktion.
Einfach instanzieren wie "Fullscreen" und die Methode set_screen_popup vor dem display aufrufen.
Das SALV kann so übrigens auch mit den Popup-Level korrekt umgehen.
Ich hab auf diesem Weg eine Instanz, die ich zu Beginn des Programms erzeugt habe, an mehreren unterschiedlichen (Popup-Level) Stellen aufrufen können und es wurde immer etwas angezeigt. Weil mich das interessiert hat, hab ich es gedebuggt und dabei herausgefunden, das das SALV-Framework bei jedem Aufruf von display eine neue ALV-Instanz erzeugt und die "alte" vernichtet. Nicht sehr performant wenn man es mehrmals verwenden möchte aber funktioniert.
Ich hatte, bevor ich auf die SALV-Popups gestoßen bin, mir was eigenes gestrickt wo ich anhand des Popup-Levels entschieden hab ob eine neue Instanz anzulegen ist oder nicht. Damit waren also zwar maximal 10 Instanzen gleichzeitig vorhanden aber mussten nur einmal erzeugt werden. Ich hab das dann aber doch (zumindest für das SALV) wieder aufgegeben.
cl_salv_table hat doch von sich aus eine "Popup"-Funktion.
Einfach instanzieren wie "Fullscreen" und die Methode set_screen_popup vor dem display aufrufen.
Das SALV kann so übrigens auch mit den Popup-Level korrekt umgehen.
Ich hab auf diesem Weg eine Instanz, die ich zu Beginn des Programms erzeugt habe, an mehreren unterschiedlichen (Popup-Level) Stellen aufrufen können und es wurde immer etwas angezeigt. Weil mich das interessiert hat, hab ich es gedebuggt und dabei herausgefunden, das das SALV-Framework bei jedem Aufruf von display eine neue ALV-Instanz erzeugt und die "alte" vernichtet. Nicht sehr performant wenn man es mehrmals verwenden möchte aber funktioniert.
Ich hatte, bevor ich auf die SALV-Popups gestoßen bin, mir was eigenes gestrickt wo ich anhand des Popup-Levels entschieden hab ob eine neue Instanz anzulegen ist oder nicht. Damit waren also zwar maximal 10 Instanzen gleichzeitig vorhanden aber mussten nur einmal erzeugt werden. Ich hab das dann aber doch (zumindest für das SALV) wieder aufgegeben.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Mit eingeschränkter Funktionalität. Versuch mal mit "add_function" einen Button zur Toolbar hinzuzufügen. Zum Beispiel.a-dead-trousers hat geschrieben: ↑27.03.2020 16:44Muss es denn ein "eigenes" Dynpro sein?
cl_salv_table hat doch von sich aus eine "Popup"-Funktion.
Da gab es schon einen Thread zu.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Klar, weil die Buttons im jeweiligen GUI-Status eingefügt werden müssen, den man mit SET_SCREEN_STATUS festlegt.ralf.wenzel hat geschrieben: ↑27.03.2020 17:50Mit eingeschränkter Funktionalität. Versuch mal mit "add_function" einen Button zur Toolbar hinzuzufügen. Zum Beispiel.
Aber ich glaub ich weiß worauf du hinauswillst:
Du möchtest die flexiblere GUI-Toolrbar des ALV nutzen und nicht den GUI-Status.
Eine Frage: Kommen bei deinem Popup wirklich so viele neue Funktionen dazu, dass man das nicht mit einer Kopie und Erweiterung des besthenden GUI-Status des SALV lösen kann? Im Sinne der Einheitlichkeit von Benutzerdialogen (eventuell auch für Batch-Input) gehe ich in letzter Zeit immer öfter in Richtung GUI-Status anstatt Toolbars. Im SAP-Gui Design sind nun mal die Buttons in Popups unten angeordnet.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Ich möchte die flexiblere Toolbar nutzen (und nutze sie auch), weil eine ALV-Funktion Bestandteil des ALVs ist und damit in dessen Control gehören.
Bei mir wird ein solcher Button (jeder SALV UC) durch eine Klasse repräsentiert, die eine Schnittstelle implementiert. Die hat Attribute (welches Icon, welcher Text, etc.) und eine Methode RUN.
Diese Klasse meldet sich per subscribe-Methode beim SALV (bzw bei dessen Toolbar) an. Über ein Iterator-Pattern rappelt die Toolbar über alle angemeldeten Funktionen und tackert die Icons auf den Screen.
Der SALV muss bei Klick auf den Button nur die Methode RUN der Schnittstelle dieses Buttons ausführen. Der SALV „weiß“ also gar nicht, welche Funktionen er hat und was die Funktion macht. So kann ich ein und dieselbe Funktion überall einhängen.
Warum ich das mache? Da muss ich nur an mein letztes Projekt denken, wo plötzlich ein FB sagte „ich brauche eine Historien-Funktion in diesem SALV... und in diesem.... und...“ und plötzlich gab es über ein halbes Dutzend SALVs mit History-Button-Anforderung.
Gerade im letzten Projekt hatten wir das oft, dass wir SALVs mehrfach brauchten. Die Sicht auf die Labordaten einer Blutspende brauchst du beim Spender, bei der Sicht auf die Spende, in der Validierungsanwendung für‘s BRF+ Regelwerk usw usf
Und wenn jemand sagt „ich hätte gern diesen SALV, nur ohne Sichern“ ruft er den einfach auf, macht ein Unsubschribe auf SAVE und fertig. Viel einfacher und einheitlicher als wenn sich jeder selbst einen häkelt. Und wenn es dann heißt „zu den Laborddaten muss noch was dazu“, weil ein neuer Virus grassiert (oha!), dann macht man das einmal und in allen ALVs die Labordaten darstellen, ist das drin.
Das klappt ganz klasse, ich habe gerade ein Demoprogramm für meinen neuen Kunden geschrieben, das genau diesen Mechanismus vorführt.
Es geht also nicht um EIN Popup, sondern um das Verhalten aller „meiner“ SALVs gleichermaßen. Darum ist das so wichtig.
Ich wünschte nur, mit der Toolbar vom Dynpro ginge das ähnlich, aber da habe ich noch keinen Weg gefunden, mit diesem recht einfachen Weg (mit hoher Kapselung, massiver Wiederverwendung, etc.) „meinen“ Mechanismus wiederzuverwenden.
Ralf
Bei mir wird ein solcher Button (jeder SALV UC) durch eine Klasse repräsentiert, die eine Schnittstelle implementiert. Die hat Attribute (welches Icon, welcher Text, etc.) und eine Methode RUN.
Diese Klasse meldet sich per subscribe-Methode beim SALV (bzw bei dessen Toolbar) an. Über ein Iterator-Pattern rappelt die Toolbar über alle angemeldeten Funktionen und tackert die Icons auf den Screen.
Der SALV muss bei Klick auf den Button nur die Methode RUN der Schnittstelle dieses Buttons ausführen. Der SALV „weiß“ also gar nicht, welche Funktionen er hat und was die Funktion macht. So kann ich ein und dieselbe Funktion überall einhängen.
Warum ich das mache? Da muss ich nur an mein letztes Projekt denken, wo plötzlich ein FB sagte „ich brauche eine Historien-Funktion in diesem SALV... und in diesem.... und...“ und plötzlich gab es über ein halbes Dutzend SALVs mit History-Button-Anforderung.
Gerade im letzten Projekt hatten wir das oft, dass wir SALVs mehrfach brauchten. Die Sicht auf die Labordaten einer Blutspende brauchst du beim Spender, bei der Sicht auf die Spende, in der Validierungsanwendung für‘s BRF+ Regelwerk usw usf
Und wenn jemand sagt „ich hätte gern diesen SALV, nur ohne Sichern“ ruft er den einfach auf, macht ein Unsubschribe auf SAVE und fertig. Viel einfacher und einheitlicher als wenn sich jeder selbst einen häkelt. Und wenn es dann heißt „zu den Laborddaten muss noch was dazu“, weil ein neuer Virus grassiert (oha!), dann macht man das einmal und in allen ALVs die Labordaten darstellen, ist das drin.
Das klappt ganz klasse, ich habe gerade ein Demoprogramm für meinen neuen Kunden geschrieben, das genau diesen Mechanismus vorführt.
Es geht also nicht um EIN Popup, sondern um das Verhalten aller „meiner“ SALVs gleichermaßen. Darum ist das so wichtig.
Ich wünschte nur, mit der Toolbar vom Dynpro ginge das ähnlich, aber da habe ich noch keinen Weg gefunden, mit diesem recht einfachen Weg (mit hoher Kapselung, massiver Wiederverwendung, etc.) „meinen“ Mechanismus wiederzuverwenden.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Mit den "dynamischen" Funktionscodes im GUI-Status könnte man sowas ähnliches bewerkstelligen. Zwar nicht unbegrenzt (max. 18?) aber dafür weitgehend kompatibel zu deinem Framework sowie ich das verstanden habe. Du musst nur einen "Wrapper" schreiben der die statischen Funktionscodes des GUI-Status in jene umwandelt die deine Subscriber verwenden. Das ist dann sowas ähnliches wie das Toolbar Control arbeitet (FCODE %_GC xx yy => SAVE). Wie man das SET PF-STATUS sauber in dein Objekt-Framework eingliedern kann, überlass ich deiner Phantasie. 😉ralf.wenzel hat geschrieben: ↑28.03.2020 09:28Ich wünschte nur, mit der Toolbar vom Dynpro ginge das ähnlich, aber da habe ich noch keinen Weg gefunden, mit diesem recht einfachen Weg (mit hoher Kapselung, massiver Wiederverwendung, etc.) „meinen“ Mechanismus wiederzuverwenden.
EDIT:
Das lässt sich sogar mit dem SALV und den dort angebotenen Funktionen zum Ein- und Ausblenden von Funktionscodes kombinieren. Man kann alle Funktionscodes über die Functions-Klasse einlesen und die nicht benötigten mittels Eigenschaft "disable" ausblenden. Einziger Wermutstropfen ist, dass man beim Wechsel oder Ändern des GUI-Status ein Buffer-Refresh ausführen muss, damit die geänderten GUI-Funktionen erkannt werden aber das passiert eher während der Entwicklung als im laufenden Betrieb.
Zuletzt geändert von a-dead-trousers am 30.03.2020 13:45, insgesamt 1-mal geändert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Das Problem ist: Wenn ich "Dummy-Funktionscodes" in einem Status definiere (F01, F02, ....) muss ich die hart mit einer Funktionstaste verdrahten. Das ist aber ungünstig, weil "Detail" sollte immer F2 haben, egal wo in der Toolbar das Icon dafür ist. Die Position des Icons mit der Funktionstaste zu belegen, ist die denkbar schlechteste Lösung.
Oder habe ich dich falsch verstanden?
Ralf
Oder habe ich dich falsch verstanden?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Shit. Da hast du natürlich recht.ralf.wenzel hat geschrieben: ↑30.03.2020 13:44Das Problem ist: Wenn ich "Dummy-Funktionscodes" in einem Status definiere (F01, F02, ....) muss ich die hart mit einer Funktionstaste verdrahten. Das ist aber ungünstig, weil "Detail" sollte immer F2 haben, egal wo in der Toolbar das Icon dafür ist. Die Position des Icons mit der Funktionstaste zu belegen, ist die denkbar schlechteste Lösung.
Oder habe ich dich falsch verstanden?
Man könnt zumindest noch die Tastenbelegung in den Wrapper mitaufnehmen. Aber dann ist die Reihenfolge der Tasten fix am GUI-Status vorgegeben.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
SAP kann echt tolle Sachen, manche sind echt weitsichtig gemacht. Aber manchmal könnte ich die Leute bei der SAP glatt verprügeln. Diesen ganzen GUI-Status braucht insgesamt kein Mensch. Meinetwegen kann man sowas optional machen quasi als Schablone für die, die das nicht von Hand schreiben wollen. Aber wenn es die Möglichkeiten signifikant einschränkt, dann tut das schon weh.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Der GUI-Status gehört nun mal mit zum System.
Baue dir doch deine eigene Toolbar.
Docking-Container nach oben, Größe auf nicht änderbar und schon kannst du dich austoben.
Zumal ich dein Problem mit den Funktionstasten nicht verstehe. du kannst doch die Funktions-Texte dynamisch verwalten. Damit kannst du einen generischen Status anlegen und alle Funktionstasten mit Variablennamen durchnummerieren. In deinem Programm kannst du dann festlegen, dass "F2" den Funktionstext "Detaildaten" bekommt.
Baue dir doch deine eigene Toolbar.
Docking-Container nach oben, Größe auf nicht änderbar und schon kannst du dich austoben.
Zumal ich dein Problem mit den Funktionstasten nicht verstehe. du kannst doch die Funktions-Texte dynamisch verwalten. Damit kannst du einen generischen Status anlegen und alle Funktionstasten mit Variablennamen durchnummerieren. In deinem Programm kannst du dann festlegen, dass "F2" den Funktionstext "Detaildaten" bekommt.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Ich bin aber darauf festgelegt, dass F2 immer an derselben Stelle liegt. Was bei F2 noch verständlich ist (weil die Detailsicht meistens ganz links steht), ist nicht zu erklären, wenn der Button "Aktivieren" mal F5 und mal Strg+F7 hat, je nachdem wo er denn gerade in der Toolbar eingehängt wurde.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
hä?
du definierst doch, welche Funktionen du auf die Funktionstasten legst...?!
du definierst doch, welche Funktionen du auf die Funktionstasten legst...?!
Vergleichbare Themen
1
Antw.
Antw.
3081
Views
Views
5
Antw.
Antw.
5968
Views
Views
Wie kann ich bestimmte Buttons im ALV (SALV,Popup) abfangen?
von einar46 » 23.07.2014 09:12 • Verfasst in ABAP Objects®
von einar46 » 23.07.2014 09:12 • Verfasst in ABAP Objects®
2
Antw.
Antw.
5159
Views
Views
3
Antw.
Antw.
2990
Views
Views
GUI Status verhindert on click Event des SALV Table
von Pinguincommander » 05.02.2019 09:51 • Verfasst in ABAP® Core
von Pinguincommander » 05.02.2019 09:51 • Verfasst in ABAP® Core
1
Antw.
Antw.
5283
Views
Views
sorted table, hashed table: Übergabe Workarea -> Performa
von Jürgen Fischer » 30.01.2006 08:09 • Verfasst in ABAP® Core
von Jürgen Fischer » 30.01.2006 08:09 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.