Select-Options an Methode übergeben

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
16 Beiträge • Seite 1 von 2 (current) Nächste
16 Beiträge Seite 1 von 2 (current) Nächste

Select-Options an Methode übergeben

Beitrag von Karl der Große (ForumUser / 1 / 0 / 0 ) »
Hallo Liebe Entwickler, ich möchte Select-Options auf Werk in meine Methode schreiben. Wie gehe ich da voran?

Data: so_plant type LOG_COMP-plant.

SELECT-OPTIONS s_plant For so_plant.

diese möchte ich meiner Methode übergeben.

Vielen Dank.

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Select-Options an Methode übergeben

Beitrag von rob_abc (ForumUser / 56 / 11 / 18 ) »
Etwas mehr eigener Code wäre toll gewesen. So weiss man ja gar nicht, an welcher Stelle zu gescheitert bist.

Code: Alles auswählen.

REPORT.

Data: so_plant type werks_d.

SELECT-OPTIONS s_plant For so_plant.


class lcl_report definition.

  public section.
    types t_plant type range of werks_d.
    class-methods main IMPORTING i_plants type t_plant.

endclass.

class lcl_report implementation.

  method main.
    cl_demo_output=>display( i_plants ).
  endmethod.

endclass.

start-of-selection.
lcl_report=>main( s_plant[] ).

Re: Select-Options an Methode übergeben

Beitrag von a-dead-trousers (Top Expert / 4285 / 214 / 1141 ) »
Alternativ kann man auch im DDIC einen Range-Tabellentyp anlegen. Dieser ist dann im ganze SAP System einsetzbar.

Es gibt übrigens schon einige Range-Tabellentypen für WERKS_D in SAP_APPL:
/SAPSLL/WERKS_R3_R_T
CFB_T_WERKS_RANGE
CURTO_WERKS_RANGE_T
MD_RANGE_T_WERKS
MNT_T_WERKS_RANGE
PLMIFO_TT_PLANT_RANGE
PRJ_T_WERKS_RANGE
RANGE_T_WERKS
RANGE_T_WERKS_D
WVFI_WERKS_RTTY
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: Select-Options an Methode übergeben

Beitrag von rob_abc (ForumUser / 56 / 11 / 18 ) »
Nutze auch gerne rsdsselopt_t anstatt vollständig zu typisieren.

Code: Alles auswählen.

DATA(l_rng) = value rsdsselopt_t( ( sign = 'I' option = 'EQ' low = variable ) ).

Re: Select-Options an Methode übergeben

Beitrag von msfox (Specialist / 307 / 50 / 63 ) »
rob_abc hat geschrieben:
01.02.2024 10:07
Nutze auch gerne rsdsselopt_t anstatt vollständig zu typisieren.

Code: Alles auswählen.

DATA(l_rng) = value rsdsselopt_t( ( sign = 'I' option = 'EQ' low = variable ) ).
Das muss man aber darauf achten, dass RSDSSELOP_ nur 45 Zeichen (CHAR) hat.

Re: Select-Options an Methode übergeben

Beitrag von DeathAndPain (Top Expert / 1797 / 214 / 396 ) »
Ich habe nicht verstanden, was eure Diskussion mit dem Thema dieses Threads zu tun hat.
adt hat geschrieben:Alternativ kann man auch im DDIC einen Range-Tabellentyp anlegen. Dieser ist dann im ganze SAP System einsetzbar.
Wozu sollte der Threadersteller das brauchen/nutzen? Er will den SELECT-OPTIONS-Befehl einsetzen, um den Parameter auf sein Selektionsbild zu bekommen. SELECT-OPTIONS erzeugt immer selber eine passende RANGES-Tabelle. Da nützt es Dir nichts, wenn Du schon eine hast.
rob_abc hat geschrieben:Nutze auch gerne rsdsselopt_t anstatt vollständig zu typisieren.
Vollständig mit allen Spalten typisieren musst Du hier so oder so nicht. Da reicht ein einfacher

Code: Alles auswählen.

DATA l_rng TYPE RANGE OF werks_d.
Deine Variante geht natürlich auch, aber in diesem Fall tendiere ich tatsächlich dazu, die explizite Deklaration für besser lesbar zu halten, da der Leser des Programms sonst erst per Doppelklick in die SE11 abspringen muss, um sich anzuschauen, wie Dein rsdsselopt_t (das er wahrscheinlich nicht auswendig kennen wird) beschaffen ist. TYPE RANGE OF werks_d hingegen erschließt sich auf den ersten Blick.

Re: Select-Options an Methode übergeben

Beitrag von ST22 (Specialist / 274 / 40 / 40 ) »
Du musst aber die Parameter einer Methode typisieren, dazu benötigst du einen Tabellentyp vom Typ Range, an den übergibt man dann den Tabellenkörper der Select Option SO_WERK[].
Andererseits in einer programmlokalen Klasse hat mit die Select Options natürlich so im Zugriff, ohne dass man die in die Klasse reinreichen muss.

Re: Select-Options an Methode übergeben

Beitrag von rob_abc (ForumUser / 56 / 11 / 18 ) »
DeathAndPain hat geschrieben:
04.02.2024 15:27
Deine Variante geht natürlich auch, aber in diesem Fall tendiere ich tatsächlich dazu, die explizite Deklaration für besser lesbar zu halten, da der Leser des Programms sonst erst per Doppelklick in die SE11 abspringen muss, um sich anzuschauen, wie Dein rsdsselopt_t (das er wahrscheinlich nicht auswendig kennen wird) beschaffen ist. TYPE RANGE OF werks_d hingegen erschließt sich auf den ersten Blick.
Per Doppelklick in der SE11 muss im Jahr 2024 hoffentlich niemand mehr nachschauen was für ein Typ ein Feld, eine Struktur oder sonst was hat, wenn es im Eclipse die ABAP Element Info View gibt.

Aber natürlich bin ich auch ein Fan davon genau zu typisieren, deshalb nutze ich rsdsselopt_t auch nur als Hilfsvariable, wenn die Methode eine RNG-Tabelle verlangt, ich aber zum Zeitpunkt des Methodenaufrufes nur eine normale Variable oder Tabelle als Ausgangsbasis habe.

Re: Select-Options an Methode übergeben

Beitrag von DeathAndPain (Top Expert / 1797 / 214 / 396 ) »
ST22 hat geschrieben:
05.02.2024 09:53
Du musst aber die Parameter einer Methode typisieren, dazu benötigst du einen Tabellentyp vom Typ Range, an den übergibt man dann den Tabellenkörper der Select Option SO_WERK[].
Andererseits in einer programmlokalen Klasse hat mit die Select Options natürlich so im Zugriff, ohne dass man die in die Klasse reinreichen muss.
Ja, und bei Selektionsparametern (einschließlich SELECT-OPTIONS) finde ich es auch legitim, dass diese global sind und vom Programmierer auch global verwendet werden, denn bei diesen Feldern ist zu jedem Zeitpunkt im Programmablauf glasklar, wo ihre Werte herkommen, und ab START-OF-SELECTION ändern sich diese auch nicht mehr. Man kann sie also aus Programmsicht wie Konstanten betrachten.
rob_abc hat geschrieben:Per Doppelklick in der SE11 muss im Jahr 2024 hoffentlich niemand mehr nachschauen was für ein Typ ein Feld, eine Struktur oder sonst was hat, wenn es im Eclipse die ABAP Element Info View gibt.
Ich bin mit den modischen Begriffen für die Eclipse-Funktionalitäten nicht so vertraut, aber wenn Du das meinst, was man zu sehen bekommt, wenn man in Eclipse den Cursor auf ein Feld stellt und F2 drückt, dann hast Du sicherlich recht. Auf die Unterscheidung zwischen SE38 und Eclipse kommt es mir hier aber auch gar nicht an; meiner Meinung nach muss man in beiden einen leichten Zugang zu derlei Informationen haben. Witzigerweise ist das auch in der SE38 mit der Taste F2 der Fall, auch wenn die dann (bei global definierten Datentypen) in die SE11 abspringt.

Dass Eclipse zum Entwickeln besser ist, bin ich komplett Deiner Meinung. Wobei ich von der Integration der Zusatzfunktionen (wie SE11 oder auch Debugging) in Eclipse nicht überzeugt bin. Ursprünglich waren diese Funktionalitäten schnarchlangsam. Das scheint mir in den letzten Jahren besser geworden zu sein, aber dennoch wirkt diese Integration aufgesetzt. Letztlich öffnet sich da in Eclipse nur ein passendes SAPGui-Fenster, und wo man im SAPGui mit Doppelklick und F3 vor und zurück navigieren kann, ist das in Eclipse nicht so nahtlos möglich, weil es sich halt in einem separaten, starren Tabreiter öffnet. Deswegen nutze ich Eclipse als SE38-Ersatz und mache alles andere (Definieren von Tabellen und Datentypen, SE16 usw.) nach wie vor im Gui. Klappt sehr gut so, und so kann ich in Eclipse beliebig viele Codefenster offen haben, ohne dass mir diese von den 6 maximal möglichen SAPGui-Modi abgezogen werden.
rob_abc hat geschrieben:Aber natürlich bin ich auch ein Fan davon genau zu typisieren, deshalb nutze ich rsdsselopt_t auch nur als Hilfsvariable, wenn die Methode eine RNG-Tabelle verlangt, ich aber zum Zeitpunkt des Methodenaufrufes nur eine normale Variable oder Tabelle als Ausgangsbasis habe.
Ich habe vor dem Problem auch schon gestanden, und die Lösung, die mir am besten gefällt, sieht so aus, dass ich zu Programmbeginn einen programmglobalen Datentyp mit sprechendem Namen deklariere. Den kann ich dann sowohl in meiner lokalen Klasse als auch im aufrufenden Programmcode verwenden, und seine Bedeutung erschließt sich dem Leser (mich selber eingeschlossen, wenn ich nach einem halben Jahr mal wieder auf den Code schaue) auf den ersten Blick.

Also:

Code: Alles auswählen.

TYPES range_of_werks_d TYPE RANGE OF werks_d.

...

CLASS whatever DEFINITION.
  METHODS methode IMPORTING r_werksd TYPE range_of_werks_d.
ENDCLASS.

...

START-OF-SELECTION.

...

DATA(l_rng) = value range_of_werks_d( ( sign = 'I' option = 'EQ' low = variable ) ).

methode( l_rng ).
Der wesentliche Vorteil besteht darin, dass ich so über den Typnamen entscheiden kann und keinen geisteskranken Namen wie rsdsselopt_t verwenden muss, nur weil der zufällig schon im DDIC existiert. Der Unterschied wirkt klein, doch ich halte ihn für gewaltig. Wer meinen (obenstehenden) Code liest, kann flüssig lesen und verstehen, ohne über die Frage zu stolpern, was das für ein Parametertyp ist und dadurch aus dem Gedankengang gerissen zu werden.

Re: Select-Options an Methode übergeben

Beitrag von a-dead-trousers (Top Expert / 4285 / 214 / 1141 ) »
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. Und auch im eigenen System ist es ab einer gewissen Größe besser, wenn man die Typdefinitionen irgendwie zentral verwalten kann. Das kann jetzt in Form eines Interfaces oder von mir aus in der PUBLIC Section einer Klasse stattfinden ... oder warte mal ... hat die SAP nicht genau dafür etwas ganz spezielles geschaffen ... wie heißt das noch gleich ... DataDictionary ???.
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: Select-Options an Methode übergeben

Beitrag von black_adept (Top Expert / 3946 / 105 / 886 ) »
DeathAndPain hat geschrieben:
05.02.2024 13:26
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Select-Options an Methode übergeben

Beitrag von black_adept (Top Expert / 3946 / 105 / 886 ) »
DeathAndPain hat geschrieben:
05.02.2024 13:26
ohne dass mir diese von den 6 maximal möglichen SAPGui-Modi abgezogen werden.
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.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Select-Options an Methode übergeben

Beitrag von black_adept (Top Expert / 3946 / 105 / 886 ) »
DeathAndPain hat geschrieben:
05.02.2024 13:26
Ich habe vor dem Problem auch schon gestanden, und die Lösung, die mir am besten gefällt, sieht so aus, dass ich zu Programmbeginn einen programmglobalen Datentyp mit sprechendem Namen deklariere. Den kann ich dann sowohl in meiner lokalen Klasse als auch im aufrufenden Programmcode verwenden, und seine Bedeutung erschließt sich dem Leser (mich selber eingeschlossen, wenn ich nach einem halben Jahr mal wieder auf den Code schaue) auf den ersten Blick.[/code]
Gerade auf das "mich selber eingeschlossen ... nach einem halben Jahr..." kann man gar nicht häufig genug hinweisen.

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. Etwa so:

Code: Alles auswählen.

CLASS lcl DEFINITION FINAL.
  PUBLIC SECTION.
    TYPES: BEGIN OF mts_selections,
             t_r_werks     TYPE RANGE OF marc-werks,
             t_r_vtweg     TYPE RANGE OF mvke-vtweg,
             flag_whatever TYPE xfeld, " Oder abap_bool oder flag
           END OF mts_selections.
    CLASS-METHODS:
      foo IMPORTING it_r_werks TYPE mts_selections-t_r_vtweg,
      bar IMPORTING is_selections TYPE mts_selections.
ENDCLASS.

SELECT-OPTIONS: s_werks FOR marc-werks,
                s_vtweg FOR mvke-vtweg.
PARAMETERS: cb_wtf AS CHECKBOX DEFAULT 'X'.

Aufruf:
  lcl=>foo( s_vtweg[] ). 
  lcl=>bar( VALUE #( t_r_werks     = s_werks[]
                     t_r_vtweg     = s_vtweg[]
                     flag_whatever = cb_wtf
                   )
          ).
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Select-Options an Methode übergeben

Beitrag von black_adept (Top Expert / 3946 / 105 / 886 ) »
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. Und auch im eigenen System ist es ab einer gewissen Größe besser, wenn man die Typdefinitionen irgendwie zentral verwalten kann. Das kann jetzt in Form eines Interfaces oder von mir aus in der PUBLIC Section einer Klasse stattfinden ... oder warte mal ... hat die SAP nicht genau dafür etwas ganz spezielles geschaffen ... wie heißt das noch gleich ... DataDictionary ???.
Hmm - SelOpts sind doch meistens an ein bestimmtes Programm gebunden. Da ist es völlig ausreichend diesem Programm Typen zu spendieren und es nicht im DDIC abzulegen.
Andererseits hat SAP ja tatsächlich den Range-Tabellentyp im DDIC vorgesehen, auch wenn das ein wenig versteckt ist. Und auch wenn man diese nicht über den normalen Verwendungsnachweis einfach findet: Tabelle DD40L, dort bei RANGE_CTYP das Datenelement angeben und man findet (hoffentlich) schon eine Rangetabelle für das gesuchte Datenelement, denn SAP hat schon für erstaunlich viele Datenelemente eine entsprechende Range angelegt. Für WERKS_D z.B. den Tabellentyp T_RANGE_WERKS

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
a-dead-trousersewx

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Select-Options an Methode übergeben

Beitrag von rob_abc (ForumUser / 56 / 11 / 18 ) »
Ich kann auch für Datenelemente nach Tabellentypen suchen und finde auch den von dir genannten. Warum der Umweg? Releaseabhängig?
2024_02_07_11_26_10_.png
Hatte auch schon einen Table Type der SAP benutzt und nach dem nächsten Upgrade war er weg :(

Vergleichbare Themen

3
Antw.
7105
Views
SELECT-OPTIONS im Methodenparameter übergeben
von snooze » 01.04.2005 13:55 • Verfasst in ABAP Objects®
6
Antw.
836
Views
Methode soll multiple Select-Options Tabellen liefern
von mazu » 08.06.2021 13:25 • Verfasst in ABAP Objects®
10
Antw.
402
Views
Tabellen aus Methode übergeben
von Nion » 11.09.2023 07:34 • Verfasst in ABAP® für Anfänger
9
Antw.
18401
Views
iTAB an Methode übergeben
von Diesel83 » 09.03.2011 19:53 • Verfasst in ABAP® für Anfänger
0
Antw.
1772
Views
select-options depend on select-options.
von dragospirnut1 » 19.07.2017 09:54 • Verfasst in ABAP® Core

Ü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

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.