Select-Options an Methode übergeben

Re: Select-Options an Methode übergeben

a-dead-trousers hat geschrieben: ↑

05.02.2024 19:44

Ja, klar man kann das Rad natürlich immer neu erfinden und in kleinen Projekten mag das durchaus lesbarer sein. Aber sobald man über Systemgrenzen hinweg arbeitet (Stichwort RFC) ist man mit dem DDIC (se11) einfach besser beraten.

An dieser Stelle reden wir aneinander vorbei. Es liegt mir fern, gegen die Benutzung des DDIC zu hetzen. Aber wenn man Datentypen von dort entlehnt, dann sollten diese nach Möglichkeit halbwegs sprechend sein. "rsdsselopt_t" ist es nicht. Wenn ich an dieser Stelle aus den von Dir genannten Gründen auf das DDIC zurückgreifen wollte, dann würde ich mir nötigenfalls dort nochmal einen passenden Range-Typ entsprechend definieren, z.B. als ZRANGE_OF_WERKS_D. Klar hat man den Datentyp dann doppelt im DDIC, aber die SAP selbst hat so unzählig viele DDIC-Typduplikate, dass es auf eine Handvoll mehr wahrhaftig nicht ankommt.

Nebenbei vermeidet man damit rob_abc's Effekt, dass der SAP-Typ mit dem nächsten Release-Upgrade weg oder - fast noch schlimmer - anders definiert ist.

black_adept hat geschrieben: ↑

06.02.2024 13:46

DeathAndPain hat geschrieben:Ja, und bei Selektionsparametern (einschließlich SELECT-OPTIONS)
[...]
und ab START-OF-SELECTION ändern sich diese auch nicht mehr. Man kann sie also aus Programmsicht wie Konstanten betrachten.

Die können sich durch den Programmfluss durchaus ändern. Mache ich zwar selten, hat aber durchaus seine Berechtigung.

In meinen Augen hat es keine Berechtigung und gibt es keine Rechtfertigung dafür, vom User auf dem Selektionsbild zu setzende Selektionsparameter nachträglich zu ändern. Mag sein, dass ABAP das technisch nicht unterbindet, aber sowas finde ich ganz schlechten Stil. Diese Felder sind global, und wenn sie irgendwo in START-OF-SELECTION plötzlich ihre Werte verändern, kann das später keiner mehr nachvollziehen, was Du da machst und warum. Eine gemeinere Falle kann man einem debuggenden Nachfolger kaum stellen!

In INITIALIZATION und AT SELECTION-SCREEN darf man da gerne dran ändern. Da unterstützt man ja nur den User beim Ausfüllen des Selektionsbildes. Aber ab START-OF-SELECTION sind das die Werte, mit denen der User den Report gestartet hat. Wenn Du dann unter bestimmten Umständen so reagieren möchtest, als hätte er anders gewählt, dann solltest Du dafür ein eigenes (möglichst nicht globales) Feld deklarieren, den Wert vom Selektionsbild hineinkopieren und damit dann weiterarbeiten. Dann sieht der Leser auf einen Blick, dass das nicht der Wert vom Selektionsbild ist und wird schauen, wie der enthaltene Wert zustande kommt.

black_adept hat geschrieben: ↑

06.02.2024 13:50

Ich habe viele meiner Kunden überzeugen können, dass der Systemparameter, der die Anzahl der Modi steuert, in Nichtproduktivsystemen auf deutlich höhere Werte gesetzt wird. Die Obergrenze 6 ist schon seit recht langer Zeit überholt.

Das geht!? Vielen Dank für den Tipp; das war mir nicht bekannt!

black_adept hat geschrieben:Ich selber mache das ähnlich, allerdings für alle Felder des Selektionsbilds gleichzeitig weil sich - zumindest bei mir - häufig genug die Notwendigkeit ergibt, einen nicht marginalen Anteil des Selektionsbilds an Modularisierungseinheiten durchzureichen.

Na ja, die sind global, und solange Du sie wie von mir oben erwähnt behandelst und nicht anfängst, irgendwo in Deinem Programm verdeckt die Benutzereingaben nachträglich zu manipulieren, haben sie aus Sicht des Programmablaufs den Stellenwert von Konstanten und können daher aus meiner Sicht problemlos als globale Felder ohne Berücksichtigung im Methodeninterface verwendet werden.