Modal Dialog: Best Approach?

Benutzeroberflächen in SAP®-Systemen.
19 Beiträge • Seite 1 von 2 (current) Nächste
19 Beiträge Seite 1 von 2 (current) Nächste

Modal Dialog: Best Approach?

Beitrag von tar (ForumUser / 76 / 16 / 26 ) »
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!
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


Re: Modal Dialog: Best Approach?

Beitrag von DeathAndPain (Top Expert / 1908 / 247 / 407 ) »
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.

Re: Modal Dialog: Best Approach?

Beitrag von black_adept (Top Expert / 4059 / 118 / 929 ) »
tar hat geschrieben:
30.08.2024 20:33

Code: Alles auswählen.

cl_gui_container=>default_screen
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Modal Dialog: Best Approach?

Beitrag von tar (ForumUser / 76 / 16 / 26 ) »
DeathAndPain hat geschrieben:
01.09.2024 19:19
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.
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.

Re: Modal Dialog: Best Approach?

Beitrag von tar (ForumUser / 76 / 16 / 26 ) »
black_adept hat geschrieben:
01.09.2024 23:11
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 und auch bis Screen9 hat leider nicht funktioniert, weil "bereits eine Liste aktiv ist".

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 😄

Re: Modal Dialog: Best Approach?

Beitrag von Lukas Sanders (ForumUser / 68 / 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.

Re: Modal Dialog: Best Approach?

Beitrag von a-dead-trousers (Top Expert / 4370 / 222 / 1174 ) »
tar hat geschrieben:
02.09.2024 00:42
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 😄
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):
whaslbecktar

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

Re: Modal Dialog: Best Approach?

Beitrag von black_adept (Top Expert / 4059 / 118 / 929 ) »
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Modal Dialog: Best Approach?

Beitrag von black_adept (Top Expert / 4059 / 118 / 929 ) »
tar hat geschrieben:
02.09.2024 00:42
Das und auch bis Screen9 hat leider nicht funktioniert, weil "bereits eine Liste aktiv ist".
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?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Modal Dialog: Best Approach?

Beitrag von tar (ForumUser / 76 / 16 / 26 ) »
black_adept hat geschrieben:
02.09.2024 17:25
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.

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
Genau das empfinde ich als sehr angenehm, weil es mir das Anlegen und die Auseinandersetzung mit diesem ganzen Dynpro-Käse erspart und bei sehr vielen Anforderungen bereits ausreicht, bei denen man einfach nur eine Liste sehen will.

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.

Re: Modal Dialog: Best Approach?

Beitrag von black_adept (Top Expert / 4059 / 118 / 929 ) »
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Modal Dialog: Best Approach?

Beitrag von JHM (Top Expert / 1197 / 1 / 197 ) »
tar hat geschrieben:
02.09.2024 22:29
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.
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

Re: Modal Dialog: Best Approach?

Beitrag von tar (ForumUser / 76 / 16 / 26 ) »
JHM hat geschrieben:
03.09.2024 15:08
Ich verstehe nicht wieso du diesen überhaupt mit angibst. Auch das WRITE SPACE ist ja ein Krücke die man eigentlich nicht braucht.
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
).
Das dumpt ohne Container.
JHM hat geschrieben:
03.09.2024 15:08
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.
Welche Vorteile bringt mir der "richtige" GUI-Status?
JHM hat geschrieben:
03.09.2024 15:08
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.
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#.
JHM hat geschrieben:
03.09.2024 15:08
Oder direkt den vorgeschlagenen POPUP_GET_VALUES...
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.

Re: Modal Dialog: Best Approach?

Beitrag von JHM (Top Expert / 1197 / 1 / 197 ) »
tar hat geschrieben:
04.09.2024 00:31
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
).
Das dumpt ohne Container.
Naja, den GUI-Status kopieren und erweitern verhindert den Dump.

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

Re: Modal Dialog: Best Approach?

Beitrag von black_adept (Top Expert / 4059 / 118 / 929 ) »
JHM hat geschrieben:
03.09.2024 15:08

Ich verstehe nicht wieso du diesen überhaupt mit angibst. Auch das WRITE SPACE ist ja ein Krücke die man eigentlich nicht braucht.
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Vergleichbare Themen

7
Antw.
5564
Views
Modal Dialog Box (Pop Up Screen)
von stony007_de » 21.02.2020 17:36 • Verfasst in Dialogprogrammierung
7
Antw.
4460
Views
Dialog zum Drucken
von Jessy83 » 26.02.2008 11:56 • Verfasst in Dialogprogrammierung
1
Antw.
2307
Views
Reaktion auf /N im Dialog?
von Hellbender » 24.01.2007 10:37 • Verfasst in Dialogprogrammierung
1
Antw.
4583
Views
ALE Verarbeitung im Dialog
von ewx » 18.06.2013 16:36 • Verfasst in Exchange Infrastructure
4
Antw.
1533
Views
Dialog Programmierung in Meldung
von Sava » 02.08.2013 07:44 • Verfasst in ABAP® für Anfänger

Aktuelle Forenbeiträge

corresponding - mapping - switch
vor 2 Stunden von tar 34 / 1028
Übertragen MINNISTAMM
vor 5 Stunden von DeathAndPain 2 / 148
Exception statt sy-subrc
vor 5 Stunden von DeathAndPain 17 / 791
Neue Themen als SAP Entwickler
Gestern von tar 156 / 23820

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

corresponding - mapping - switch
vor 2 Stunden von tar 34 / 1028
Übertragen MINNISTAMM
vor 5 Stunden von DeathAndPain 2 / 148
Exception statt sy-subrc
vor 5 Stunden von DeathAndPain 17 / 791
Neue Themen als SAP Entwickler
Gestern von tar 156 / 23820

Unbeantwortete Forenbeiträge

aRFC im OO-Kontext
vor 2 Tagen von ralf.wenzel 1 / 373
EPC QR Code in Smartforms ohne CF_LF
vor einer Woche von Thomas J. 1 / 1555
Hilfe bei SWEC/SWE2
letzen Monat von retsch 1 / 7098