Alternativen zu FM POPUP_GET_VALUES / POPUP_TO_CONFIRM...

Re: Alternativen zu FM POPUP_GET_VALUES / POPUP_TO_CONFIRM..

Hallo Nescio,

ich habe die Popup FuBas einfach in einer statischen Methode verschalt

Je nachdem welches Popup ich gerne hätte, übergebe ich ein "Popupmodus"

Die "alten" Fubas funktionieren ja soweit noch gut, deswegen verwende ich die immer noch.

Ich weiß, ist nicht grad die Antwport auf deine Frage

Grüße 4Byte

Re: Alternativen zu FM POPUP_GET_VALUES / POPUP_TO_CONFIRM..

Das Problem ist, dass du weiterhin ein altmodisches Objekt (Programm oder Funktionsgruppe) als Träger und zur Verarbeitung für die Dynpros benötigst.
Deswegen gibt es da auch nichts neues.

Mich stört das auch immer wieder. Zumal man diese Popups nicht in der Größe ändern kann, was ebenfalls immer wieder nervt.
Leider ist aber auch CL_GUI_DIALOGBOX_CONTAINER keine Alternative, weil der ausschließlich als amodales Element designt wurde. Ich habe auch bisher keine Möglichkeit gefunden, das zu ändern. Zum Beispiel in Verbindung mit Messaging Channels bei dem man das Programm selber so lange auf eine Antwort vom Dialog warten lässt, bis der Anwender im Dialog "OK" oder "Abbrechen" gedrückt hat.

Eine Größenänderung kann man umständlich über Funktionstasten erreichen indem man Drucktasten "Horizontal verkleinern/ vergrößern" und "Vertikal verkleinern/ vergrößern" anbietet und je nach Wunsch den CALL SCREEN starting at ... ending at mit angepassten Werten ausführt.

Man könnte sich also so ein Rumpf-Popup mit den Grundfunktionen basteln (ok, abbrechen, vergrößern, verkleinern) und im Dynpro ein Custom Control einbinden in das man dann ein GRID, HTML-Control, Text-Control oder sonstiges einbinden kann. Man hat allerdings nach wie vor ein Dynpro...

Mit etwas Arbeit kann man die Popups dann auch noch mit schicken Langtexten ausstatten:
https://www.tricktresor.de/blog/pimp-my ... sterpiece/

Re: Alternativen zu FM POPUP_GET_VALUES / POPUP_TO_CONFIRM..

Die werden glatt in meine Klasse aufgenommen

Den Beschreibungstext von POPUP_TO_CONFIRM_LOSS_OF_DATA hast Du aber gelesen?

ich stört das auch immer wieder. Zumal man diese Popups nicht in der Größe ändern kann, was ebenfalls immer wieder nervt.
Leider ist aber auch CL_GUI_DIALOGBOX_CONTAINER keine Alternative, weil der ausschließlich als amodales Element designt wurde.

Ich verstehe Dein Problem nicht. Es liegt doch in der Natur eines Popups, amodal zu sein?!

Eine Größenänderung kann man umständlich über Funktionstasten erreichen indem man Drucktasten "Horizontal verkleinern/ vergrößern" und "Vertikal verkleinern/ vergrößern" anbietet und je nach Wunsch den CALL SCREEN starting at ... ending at mit angepassten Werten ausführt.

Wer will denn bitte die Größe eines Popups mit Drucktasten verändern? Ein Popup liest man sich durch (oder auch nicht) und klickt es dann weg, aber man zuppelt nicht an seiner Größe herum. Wie groß es sinnvollerweise sein soll, entscheidet allenfalls derjenige, der es programmiert. Also kann man seiner Methode (optionale) Parameter dafür mitgeben und diese 1:1 an den CALL SCREEN durchreichen. Wobei Du natürlich trotzdem ein Trägerprogramm brauchst. Daran wird sich wohl auch nichts mehr ändern, denn Ziel des Spieles ist, alles in HTML-basiertes Geraffel umzusetzen, auch wenn der Fiori-Kram verglichen mit klassischem SAPGui-ABAP ein Alptraum ist, insbesondere hinsichtlich des Debuggings.

Re: Alternativen zu FM POPUP_GET_VALUES / POPUP_TO_CONFIRM..

Nein. Popups sind modal.

Hast wohl recht. hab den Begriff so lange nicht mehr gebraucht, dass ich ihn falsch herum aus meiner Erinnerung gekramt habe.

Und doch: ich möchte manchmal als Anwender die Größe eines Dialoges ändern können, weil
- meine Auflösung eine andere ist, als die des Programmierers

Selbr schuld, wenn Du SAP auf'm Handy machst. Neumodischer Schnickschnack. Auch wenn Deine Brille nicht mehr adäquat ist, ist eine Rentnerschriftgröße nicht die Alternative zum Optiker.

- der Programmierer die Daten wichtiger fand, als die Doku und deswegen der Infobereich nur ganz kleIn ist

Wenn das Popup ein komplettes ALV mit Daten enthält. Das halte ich aber eher für die Ausnahme, und es sprengt den Rahmen eines klassischen Popups Marke POPUP_TO_CONFIRM bei weitem. Von solchen war hier ja die Rede; gestört hat nur, dass POPUP_TO_CONFIRM halt noch ein FB ist und nichts Objektorientiertes.

Na klar, wenn Du eine richtige Datenausgabe anzeigen möchtest, dann macht ein größenveränderliches Fenster Sinn. Aber dann würde ich auch schon darüber nachdenken, den Aufwand zu treiben und dafür ein dezidiertes Dynpro zu schreiben, wo ich dann hinsichtlich der Funktionalität keinerlei Beschränkungen unterworfen bin.

Re: Alternativen zu FM POPUP_GET_VALUES / POPUP_TO_CONFIRM..

Du kannst den Baustein aber trotzdem benutzen. Das "Do not use" haben sie nur reingeschrieben, weil ihnen seinerzeit die Zahl der ganzen POPUP_TO_CONFIRM_*-Bausteine aus dem Ruder gelaufen ist und sie daher den allgemeinen POPUP_TO_CONFIRM geschrieben haben, der sie alle ersetzen soll. Das ist aber schon viele Jahre her, und es gibt sie alle heute noch, insofern kann man vermuten, dass da ebenso wenig dran geschraubt werden wird wie dass bei diversen SAP-Funktionsbausteinen der Hinweis in der Online-Doku "Diese Dokumentation erfüllt noch nicht die Qualitätskriterien der SAP und wird noch überarbeitet" jemals durch eine vernünftige Doku ersetzt werden wird.

Aber klar sein sollte man sich halt über diese Umstände.

Re: Alternativen zu FM POPUP_GET_VALUES / POPUP_TO_CONFIRM..

Gar nichts aber da sind die Texte(Infomeldung Button etc) schon richtig gesetzt

Ich hätte mir dann die kurze Arbeit gespart, dass selber mit dem POPUPTO_CONFIRM zu bauen

Grüße 4Byte