Modal Dialog: Best Approach?
Aloha,
wie kann man in einem eigenen (OO-nahen) Report per Doppelklick in eine ALV/SALV-Zeile einen Modaldialog aufrufen, der (ähnlich der sonst üblichen Detailansicht, bspw. in SE16N) die Tabellenstruktur untereinander als editierbare Eingabefelder mit den entsprechenden Zeileninhalten und Suchhilfen bereitstellt?
1. Ist das in SAP überhaupt möglich?
2. Auch ohne jedesmal umständlich gesondertes Dynpro-Gedöns anlegen zu müssen?
3. Auch dynamisch? D.h. einmalig eine Klasse/Funktionsgruppe/whatever aufbauen, die ein allgemeines editierbares Modal-Popup bereitstellt?
Ich verzweifel mit SAP bereits an meinem momentanen Ansatz, bei dem ich nach dem generierten Selection-Screen 1000 ein SALV ohne explizites Dynpro/Screen darstelle (via cl_gui_container=>default_screen und write space), was zwar funktioniert, aber dann lässt sich partout kein weiteres ALV in einem expliziten Modaldynpro 0010 mehr darstellen. Wenn das ginge, hätte ich zumindest eine horizontale Eingabemöglichkeit (durch das editierbare ALV). Schöner wäre es indes untereinander (ähnlich der Detailsicht in SE16N).
Vielen Dank und viele Grüße!
wie kann man in einem eigenen (OO-nahen) Report per Doppelklick in eine ALV/SALV-Zeile einen Modaldialog aufrufen, der (ähnlich der sonst üblichen Detailansicht, bspw. in SE16N) die Tabellenstruktur untereinander als editierbare Eingabefelder mit den entsprechenden Zeileninhalten und Suchhilfen bereitstellt?
1. Ist das in SAP überhaupt möglich?
2. Auch ohne jedesmal umständlich gesondertes Dynpro-Gedöns anlegen zu müssen?
3. Auch dynamisch? D.h. einmalig eine Klasse/Funktionsgruppe/whatever aufbauen, die ein allgemeines editierbares Modal-Popup bereitstellt?
Ich verzweifel mit SAP bereits an meinem momentanen Ansatz, bei dem ich nach dem generierten Selection-Screen 1000 ein SALV ohne explizites Dynpro/Screen darstelle (via cl_gui_container=>default_screen und write space), was zwar funktioniert, aber dann lässt sich partout kein weiteres ALV in einem expliziten Modaldynpro 0010 mehr darstellen. Wenn das ginge, hätte ich zumindest eine horizontale Eingabemöglichkeit (durch das editierbare ALV). Schöner wäre es indes untereinander (ähnlich der Detailsicht in SE16N).
Vielen Dank und viele Grüße!
Zuletzt geändert von tar am 02.09.2024 10:35, insgesamt 1-mal geändert.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
ALVs können doch selbst auch editierbar gesteuert werden. Wäre das nicht der direkteste Ansatz für Dein Problem? Wenn das ALV selber editierbar ist, brauchst Du kein modales Fenster mehr, das letztlich den gleichen Inhalt nochmal in editierbarer Form enthält.
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Da ich so selten modale Dialogfenster baue weiß ich es nicht aus dem Kopf: Probier mal anstatt cl_gui_container=>default_screen cl_gui_container=>screen0
M.E. solltest du dann zwar weiterhin Probleme haben Folgedynpros auf der obersten Ebene darzustellen, aber ein Modalfenster ( wenn es auf einen modalen Dynpro gebunden ist ) sollte eigentlich sichtbar sein.
Das ist korrekt, finde ich aber erfahrungsgemäß aus mehreren Gründen nicht gut (vorrangig, weil Bearbeitungen in einer großen Liste schnell zu Fehleingaben führen) und wesentlich eleganter, wenn es (via Doppelklick) ein Popup für die zu ändernde Zeile gibt, bei dem erst nach einem Klick auf "OK" die zugehörigen Daten wirklich verändert/gespeichert werden. In diesen Event/UCOMM/OK-CODE gehören dann auch weitere, ggf. komplexere Validierungen und Anzeigeanpassungen (Einfärbungen, whatever). In das Popup könnte zudem auch ein "Lösch"-Button.DeathAndPain hat geschrieben: ↑01.09.2024 19:19ALVs können doch selbst auch editierbar gesteuert werden. Wäre das nicht der direkteste Ansatz für Dein Problem? Wenn das ALV selber editierbar ist, brauchst Du kein modales Fenster mehr, das letztlich den gleichen Inhalt nochmal in editierbarer Form enthält.
Das und auch bis Screen9 hat leider nicht funktioniert, weil "bereits eine Liste aktiv ist".black_adept hat geschrieben: ↑01.09.2024 23:11Da ich so selten modale Dialogfenster baue weiß ich es nicht aus dem Kopf: Probier mal anstatt cl_gui_container=>default_screen cl_gui_container=>screen0
M.E. solltest du dann zwar weiterhin Probleme haben Folgedynpros auf der obersten Ebene darzustellen, aber ein Modalfenster ( wenn es auf einen modalen Dynpro gebunden ist ) sollte eigentlich sichtbar sein.
Ich tüftele gerade daran, das einmalig über eine eigene Funktionsgruppe umzusetzen.
Der erste Wurf mit SALV- oder eingabebereiter ALV-Anzeige funktioniert bereits, wobei man hier eine beliebige Tabellenstruktur und auch eine eigene Klasse zur etwaigen Behandlung der Standard-Events mitgeben kann. Damit konnte ich bspw. dieselbe Zeile via Doppelklick zigmal als weiteres Popup öffnen 😁
Zur allgemeinen dynamischen Übersichtsanzeige ist das schon mal nicht schlecht und klar, man kann hier eine Art Modal für 1-zeilige Tabellen aufbauen, aber für Änderungseingaben finde ich die SE16N-Detaildarstellung untereinander via Table Control wesentlich schöner.
Da bin ich grad noch am überlegen, wie ich mit den unterschiedlichen Datentypen umgehen und etwaig zugehörige Suchhilfen einbinden könnte. Vielleicht reichen dazu bereits die Daten aus dem generierten Feldkatalog aus der SALV... Rocket Science 😄
Beitrag
von Lukas Sanders (ForumUser / 69 / 7 /
34
)
»
Hallo,
wenn die aktive Liste das Problem ist, geht es vielleicht, wenn der SALV in einen Custom Container auf einem Dynpro eingebettet wird.
Ansonsten könnte man einen zweiten SALV als Pop-Up einblenden und diesen editierbar schalten, falls das ausreicht (Spalte 1 Feldname, Spalte 2 Feldinhalt). Die Tabelle darin ließe sich dann auch entsprechend dynamisch aufbauen.
wenn die aktive Liste das Problem ist, geht es vielleicht, wenn der SALV in einen Custom Container auf einem Dynpro eingebettet wird.
Ansonsten könnte man einen zweiten SALV als Pop-Up einblenden und diesen editierbar schalten, falls das ausreicht (Spalte 1 Feldname, Spalte 2 Feldinhalt). Die Tabelle darin ließe sich dann auch entsprechend dynamisch aufbauen.
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Als "allgemeinen" Datentyp kannst du LVC_VALUE nehmen. Das ist der Datentyp den das (S)ALV intern verwendet und somit der maximalen Eingabelänge von 128 Zeichen entspricht. Darauf aufbauend musst du dann nur noch die jeweiligen Formatierungen (z.B. für Zahlen, Datum, Zeiten usw.) für die Aus- und Eingabe realisieren.
ODER
Du benutzt für die Darstellung die Klasse CL_WDY_WB_PROPERTY_BOX. Das ist ein ALV Grid das für die zeilenweise Darstellung von Eigenschaften (oder Feldinhalten) gedacht ist. Verwendet wird das beispielsweise in der SFP oder in der Webdynpro Verwaltung.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag (Insgesamt 2):
whaslbeck • tar
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 black_adept (Top Expert / 4099 / 128 /
941
)
»
Hmmm - einen Beitrag von gestern hatte ich wohl nicht abgeschickt. Hast du mal den FuBa POPUP_GET_VALUES ausprobiert. Vielleicht macht der schon das was du möchtest.
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Aber du rufst den modalen Dialog schon mit CALL SCREEN xxxx STARTING AT ... auf um den Popuplevel zu erhöhen und somit von SCREEN0 auf SCREEN1 zu wechseln?
Wir reden da etwas aneinander vorbei. Meine Ausgangssituation ist ein Report, der gänzlich ohne selbst angelegte Dynpros funktioniert. Es gibt da also keinen (weiteren) SCREEN, den man mit STARTING AT rufen könnte. Es gibt lediglich (und das auch nicht immer) den (durch die Select-Options/Parameter) generierten SCREEN 1000 und einen pseudo-generierten CL_GUI_CONTAINER=>DEFAULT_SCREEN, der letztlich beim Erzeugen des (S)ALV genutzt und mittels WRITE SPACE erzeugt wird. Man kann stattdessen auch SCREEN0-9 angeben, was rein gar nichts an der Grundsituation ändert.black_adept hat geschrieben: ↑02.09.2024 17:25Aber du rufst den modalen Dialog schon mit CALL SCREEN xxxx STARTING AT ... auf um den Popuplevel zu erhöhen und somit von SCREEN0 auf SCREEN1 zu wechseln?
Beispiel:
Code: Alles auswählen.
report z_show_salv.
" --- get data ------------------------------------------------------
select *
into table @data(lt_data)
from t100 up to 20 rows.
data lo_salv type ref to cl_salv_table.
" --- prepare salv --------------------------------------------------
try.
cl_salv_table=>factory(
exporting
r_container = cl_gui_container=>default_screen
importing
r_salv_table = lo_salv
changing
t_table = lt_data
).
lo_salv->get_columns( )->set_optimize( abap_true ).
lo_salv->get_functions( )->set_default( abap_true ).
lo_salv->get_selections( )->set_selection_mode( if_salv_c_selection_mode=>cell ).
catch cx_salv_data_error.
catch cx_salv_existing.
catch cx_salv_msg.
catch cx_salv_wrong_call.
endtry.
" --- display salv --------------------------------------------------
lo_salv->display( ). " usually salv is shown here but screen is not generated, yet
write space. " screen is generated => salv is finally shown
Meine Frage hier zielt nun darauf, wie ich darauf aufbauend via Doppelklick ein Popup zur Zeilenanzeige & -manipulation erhalte: einen Modaldialog. Der muss aber in einem anderen SCREEN hängen und (wie du richtig anmerkst) muss dieser SCREEN irgendwo mittels STARTING AT gerufen werden. Das geht also nur via explizit selbst angelegtem SCREEN.
Um mir nun zu ersparen, mich jedesmal wieder mit diesem Dynpro-Käse für einen derartigen Modaldialog auseinanderzusetzen, lagere ich diese Logik nun einmalig in eine explizite Funktionsgruppe aus, in der ich ein Dynpro für den CALL SCREEN ... STARTING AT samt sonstigen Dynpro-Käse erstelle. Dafür muss dieser Modaldialog natürlich allgemein verwendbar sein, d.h. dynamisch aufgebaut werden können, ganz gleich wie die übergebene Zeilenstruktur aussieht.
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Moin tar,
wie du verwende ich den "Trick" mit dem Überlagern der Listausgabe auch sehr gerne, zumal man damit auch einfach einen GUI-Status setzen kann, der die Programmfunktionalität von der ALV-Standardfunktionalität schon optisch trennt.
Und ja - so eine Funktionsgruppe um einen Dynpro zu haben, mit dem man was machen kann ist absolut üblich.
Da du meine Freunde, die Dynpros, scheinbar hasst, und du dir das sparen willst könntest du alternativ noch versuchen das Detail mittels eines auf 100% Breite geschalteten Dockingcontainers darzustellen, der den die Listausgabe überlagernden SALV zur Seite schiebt und damit alleinig sichtbar ist.
Oder du arbeitest mit einem CL_GUI_DIALOGBOX_CONTAINER, welcher aber nicht modal ist sondern die SALV-Funktionalitäten weiterhin aktiv lässt.
wie du verwende ich den "Trick" mit dem Überlagern der Listausgabe auch sehr gerne, zumal man damit auch einfach einen GUI-Status setzen kann, der die Programmfunktionalität von der ALV-Standardfunktionalität schon optisch trennt.
Und ja - so eine Funktionsgruppe um einen Dynpro zu haben, mit dem man was machen kann ist absolut üblich.
Da du meine Freunde, die Dynpros, scheinbar hasst, und du dir das sparen willst könntest du alternativ noch versuchen das Detail mittels eines auf 100% Breite geschalteten Dockingcontainers darzustellen, der den die Listausgabe überlagernden SALV zur Seite schiebt und damit alleinig sichtbar ist.
Oder du arbeitest mit einem CL_GUI_DIALOGBOX_CONTAINER, welcher aber nicht modal ist sondern die SALV-Funktionalitäten weiterhin aktiv lässt.
Ich verstehe nicht wieso du diesen überhaupt mit angibst. Auch das WRITE SPACE ist ja ein Krücke die man eigentlich nicht braucht.
Wenn du gar keinen Container mit gibst, dann wird der SALV doch automatisch als FullScreen dargestellt. Und man erhält dann auch einen "richtigen" GUI Status. Den man dann auch via set_screen_status() selber setzten kannst.
In deinem Beispiel drei Spalten auskommentieren:
Code: Alles auswählen.
report z_show_salv.
" --- get data ------------------------------------------------------
select *
into table @data(lt_data)
from t100 up to 20 rows.
data lo_salv type ref to cl_salv_table.
" --- prepare salv --------------------------------------------------
try.
cl_salv_table=>factory(
* exporting
* r_container = cl_gui_container=>default_screen
importing
r_salv_table = lo_salv
changing
t_table = lt_data
).
lo_salv->get_columns( )->set_optimize( abap_true ).
lo_salv->get_functions( )->set_default( abap_true ).
lo_salv->get_selections( )->set_selection_mode( if_salv_c_selection_mode=>cell ).
catch cx_salv_data_error.
catch cx_salv_existing.
catch cx_salv_msg.
catch cx_salv_wrong_call.
endtry.
" --- display salv --------------------------------------------------
lo_salv->display( ). " usually salv is shown here but screen is not generated, yet
*write space. " screen is generated => salv is finally shown
Wenn du den SALV als PopUp haben mächtest, setzt du vor dem Display via SET_SCREEN_POPUP( ) die Koordinaten. Dann hast du dein PopUp! Wegen SALV erstmal nicht eingabebereit, dafür gäbe es aber auch Wege.
Oder direkt den vorgeschlagenen POPUP_GET_VALUES...
Gruß Hendrik
Darum:
Code: Alles auswählen.
mo_salv->get_functions( )->add_function(
name = |BTN_EDIT|
icon = |{ icon_edit_file }|
text = |Edit|
tooltip = |Bearbeiten|
position = if_salv_c_function_position=>right_of_salv_functions
).
Welche Vorteile bringt mir der "richtige" GUI-Status?
Erst ab SAP v7.56 - viele Kunden tungeln noch mit SAP v7.50 rum. Es gibt wohl auch irgendeinen Trick, das pre-v7.56 hinzubiegen - den hab ich aber noch nicht herausgefunden. Bliebe ALV oder TABLE_CONTROL samt SCREEN. Mittlerweile finde ich jedoch die vorgeschlagene CL_WDY_WB_PROPERTY_BOX dafür am geeignetsten - erinnert mich an das PropertyGrid aus C#.
Der quittiert immer mit Fehler - geht wohl nur mit DICT-Tables?
... Ah, der ginge für Einzelwerte.
Die ganze Struktur samt Eingabe- & Suchhilfen zu ändern, fände ich da wesentlich besser. Bin aber schon dran. Es dauert nur noch etwas, weil hier ständig was dazwischenkommt.
Naja, den GUI-Status kopieren und erweitern verhindert den Dump.tar hat geschrieben: ↑04.09.2024 00:31Darum:
Das dumpt ohne Container.Code: Alles auswählen.
mo_salv->get_functions( )->add_function( name = |BTN_EDIT| icon = |{ icon_edit_file }| text = |Edit| tooltip = |Bearbeiten| position = if_salv_c_function_position=>right_of_salv_functions ).
Persöhnlich finde ich den GUI Status besser verwendbar, er bietet auch mehr Funktionen (z.B. Zwischensummenstufe setzten). Man kann Funktioncode über das OK-Feld eingeben, braucht also nicht nach Buttons/Menueinträgen suchen.
Nebenbei wird der SALV dann auch so verwendet, wie von SAP vorgesehen. ZReports sehen dann auch wie Standard-Reports aus.
Und für mich am wichtigsten: Er kann auch im Hintergrundjob ausgeführt werden ohne im Dump zu Enden! In Verbindung mit einem ALV-EXTRACTOR-Programm bekomme ich so den SALV via Job als Mail/Datei extrahiert.
Und es verhindert deine Probleme mit verschiedenen ALV-Rufen im gleichen Programm.
Wenn also nur das einfache Hinzufügen von Funktions-Button die Motivation ist, dann fängt man sich damit doch sehr viele Probleme ein.
Gruß Hendrik
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Der SALV im Fullscreenmodus verhält sich an diversen Stellen etwas anders als im auf einen Dynpro gebundenen Modus. Wenn ich mich recht entsinne ( habe den Fullscreen zu lange nicht mehr verwendet ) konnte man im Fullscreenmodus die Exceptions z.B. nicht auf die kurzen LEDs umschalten sondern muss immer mit der langen Ampel arbeiten. Der Aufruf funktioniert zwar und es gibt auch keine Fehlermeldung, aber die LEDs bzw. die anderen Darstellungen die es noch gibt, werden einfach nicht dargestellt. Ok - nicht wirklich weltbewegend, aber ich mag halt lieber die LEDs. Und es gab/gibt noch diverse andere Sachen, wo es sich halt marginal unterschiedlich (vor allem zum Cl_gui_alv_grid ) verhält.
Vergleichbare Themen
7
Antw.
Antw.
5672
Views
Views
Modal Dialog Box (Pop Up Screen)
von stony007_de » 21.02.2020 17:36 • Verfasst in Dialogprogrammierung
von stony007_de » 21.02.2020 17:36 • Verfasst in Dialogprogrammierung
7
Antw.
Antw.
4778
Views
Views
1
Antw.
Antw.
2553
Views
Views
1
Antw.
Antw.
4926
Views
Views
4
Antw.
Antw.
1638
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
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.