Interne Tabelle als ALV

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

Interne Tabelle als ALV

Beitrag von Lbyte (ForumUser / 18 / 0 / 0 ) »
Hallo zusammen,

ich schreibe momentan einen Report bei dem ich eine interne Tabelle aus mehreren vorhanden Tabellen erstellen, und die Ergebnisse dann als ALV ausgeben möchte.

Mich würde interessieren welcher FuBa sich hier eher eignet:

REUSE_ALV_GRID_DISPLAY

oder

DB2_DISPLAY_ITAB_TO_ALV_GRID.

Könnte mir jemand den Unterschied der beiden bzw die Vor,- und Nachteile erläutern.


Lieben Gruß

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


Re: Interne Tabelle als ALV

Beitrag von fr-g (ForumUser / 76 / 12 / 25 ) »
Deine Frage kann ich dir leider nicht beantworten... aber ich würde dir empfehlen, direkt die SALV-Klassen zu probieren, wenn nichts dagegen spricht:

Code: Alles auswählen.

DATA: alv TYPE REF TO CL_SALV_TABLE,
      itab TYPE "dein itab-Typ

cl_salv_table=>factory(
   IMPORTING
      r_salv_table = alv
   CHANGING
      t_table      = itab ).
alv->display( ).
Einfacher kann man imo keinen ALV ausgeben ;)

Re: Interne Tabelle als ALV

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Die Frage ist halt, wie bequem diese Klasse zu handhaben ist, wenn man mehr als gar nichts braucht, beispielsweise einen vernünftigen (d.h. nicht blind auf das DDIC vertrauenden) Feldkatalog. Gehen wird es sicherlich, aber OO ist oft sehr umständlich.

Der Klassiker ist der REUSE_ALV_GRID_DISPLAY. Den anderen Baustein kenne ich nicht, was mich zu der Vermutung bringt, dass es sich dabei um einen Exoten handelt, der wahrscheinlich keine so gute Wahl ist.

Re: Interne Tabelle als ALV

Beitrag von fr-g (ForumUser / 76 / 12 / 25 ) »
Was ist denn am FuBa-ALV-Feldkatalog vernünftiger? Ist eine ernst gemeinte Frage. Ich kenn mich eigentlich nur mit dem OO-ALV aus und bin da bis jetzt kaum an Grenzen gestoßen. Ich kann ja durchaus noch einige Anpassungen am ALV vornehmen und muss mich nicht mit den DDIC-Werten zufrieden geben. Und der Aufruf der zwei drei Methoden macht mein Programm ja noch nicht komplett objektorientiert.
Was wäre ein Anwendungsbeispiel, dass mit REUSE_ALV_GRID_DISPLAY besser geht? Würde mich wirklich interessieren :)

Folgende Benutzer bedankten sich beim Autor fr-g für den Beitrag:
ST22


Re: Interne Tabelle als ALV

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Na ja, wenn ich ein ALV nutze, dann sieht mein Hauptprogramm in etwa so aus:

Code: Alles auswählen.

DATA: ALV_FIELDCAT   TYPE SLIS_T_FIELDCAT_ALV WITH HEADER LINE,
      ALV_LAYOUT     TYPE SLIS_LAYOUT_ALV,
      ALV_VARIANT    LIKE DISVARIANT.

PERFORM ALV_LAYOUT_ERZEUGEN.
PERFORM ALV_AUSGEBEN. " interne Tabelle mit ALV-Daten heißt in diesem Beispiel M
    
*&---------------------------------------------------------------------*
*&      Form  ALV_LAYOUT_ERZEUGEN
*&---------------------------------------------------------------------*
FORM ALV_LAYOUT_ERZEUGEN.
  CONSTANTS X VALUE 'X'.
  REFRESH ALV_FIELDCAT.
  ALV_LAYOUT-COLWIDTH_OPTIMIZE = SPACE.
*  ALV_LAYOUT-INFO_FIELDNAME = 'LINECOLOR'. " Feld für Zeilenfarbe
  ALV_LAYOUT-ZEBRA = X.
  ALV_LAYOUT-CELL_MERGE = X.

  ALV_VARIANT-REPORT = SY-REPID.
  ALV_VARIANT-HANDLE = 'HAUPT'.

  PERFORM NONDDIC_FIELDCATENTRY USING 8 'N' 'PERNR' 'Persnr' 'Personalnr' 'Personalnummer' SPACE SPACE.
  PERFORM NONDDIC_FIELDCATENTRY USING ... all die anderen Spalten mit Komponentenbezeichnung, Kurztext, mittellangem Text und Langtext sowie Flag für Groß/Kleinschreibung und NO_OUT
ENDFORM.                    " ALV_LAYOUT_ERZEUGEN

*&---------------------------------------------------------------------*
*&      Form  NONDDIC_FIELDCATENTRY
*&---------------------------------------------------------------------*
FORM NONDDIC_FIELDCATENTRY  USING OUTPUTLEN INTTYPE FIELDNAME SELTEXT_S SELTEXT_M SELTEXT_L LOWERCASE NO_OUT.
  ALV_FIELDCAT-OUTPUTLEN = OUTPUTLEN.
  ALV_FIELDCAT-INTTYPE = INTTYPE.
  ALV_FIELDCAT-FIELDNAME = FIELDNAME.
  ALV_FIELDCAT-SELTEXT_S = SELTEXT_S.
  ALV_FIELDCAT-SELTEXT_M = SELTEXT_M.
  ALV_FIELDCAT-SELTEXT_L = SELTEXT_L.
  ALV_FIELDCAT-LOWERCASE = LOWERCASE.
  ALV_FIELDCAT-NO_OUT = NO_OUT.
  APPEND ALV_FIELDCAT.
ENDFORM.                    " NONDDIC_FIELDCATENTRY

*&---------------------------------------------------------------------*
*&      Form  ALV_AUSGEBEN
*&---------------------------------------------------------------------*
FORM ALV_AUSGEBEN.
  DATA REPID LIKE SY-REPID.
  MOVE SY-REPID TO REPID.

  CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
    EXPORTING
      I_CALLBACK_PROGRAM      = REPID
     I_CALLBACK_PF_STATUS_SET = 'SET_PF_STATUS'
      I_CALLBACK_USER_COMMAND = 'USER_COMMAND'
      IS_LAYOUT               = ALV_LAYOUT
      IT_FIELDCAT             = ALV_FIELDCAT{} " sind eckige Klammern, aber die mutieren optisch im Forum
      I_SAVE                  = 'U'
      IS_VARIANT              = ALV_VARIANT
    TABLES
      T_OUTTAB                = M.
ENDFORM.                    " ALV_AUSGEBEN

*&---------------------------------------------------------------------*
*&      Form  SET_PF_STATUS
*&---------------------------------------------------------------------*
FORM SET_PF_STATUS USING RT_EXTAB TYPE SLIS_T_EXTAB.
  SET PF-STATUS 'ALV'.
ENDFORM.                    " SET_PF_STATUS

*&---------------------------------------------------------------------*
*&      Form  USER_COMMAND
*&---------------------------------------------------------------------*
FORM USER_COMMAND USING I_UCOMM I_SELFIELD TYPE SLIS_SELFIELD.
  DATA: DOKUOBJEKT TYPE DOKHL-OBJECT.
  CASE I_UCOMM.
    WHEN 'USE'. " Programmdokumentation anzeigen
      DOKUOBJEKT = SY-REPID.
      CALL FUNCTION 'DOCU_CALL'
        EXPORTING
          DISPL      = 'X'
          DISPL_MODE = '2'
          ID         = 'RE'
          LANGU      = 'D'
          OBJECT     = DOKUOBJEKT.
    WHEN '&IC1'. " Doppelklick auf ALV-Zeile
      CLEAR M.
      READ TABLE M INDEX I_SELFIELD-TABINDEX.
      CHECK NOT M-PERNR IS INITIAL.
      " Bei Doppelklick in die PA20 abspringen, sofern entsprechende Berechtigung vorliegt
      AUTHORITY-CHECK OBJECT 'S_TCODE' ID 'TCD' FIELD 'PA20'.
      CHECK SY-SUBRC = 0.
      CALL FUNCTION 'HR_CHECK_AUTHORITY_PERNR'
        EXPORTING  PERNR = M-PERNR
        EXCEPTIONS NO_AUTHORIZATION_FOR_PERNR = 1.
      IF SY-SUBRC <> 0.
        MESSAGE TEXT-NOA TYPE 'S' DISPLAY LIKE 'E'.
        EXIT.
      ENDIF.
      SET PARAMETER ID 'PER' FIELD M-PERNR.
      CALL TRANSACTION 'PA20' AND SKIP FIRST SCREEN.
  ENDCASE.
ENDFORM.                    " USER_COMMAND
Das ist bedeutend länger als das, was Du geschrieben hast, aber dafür gebe ich bei jeder Spalte zu meinem Programm passende Spaltenüberschriften an, statt darauf zu vertrauen, dass das DDIC schon was Gutes bieten wird (häufig hat man ja auch programmspezifische Spalten, die es im DDIC gar nicht gibt). Ich kann die Felder nach Maß attributieren, etwa per 'X' beim NO_OUT-Parameter Spalten hinzufügen, die man meist nicht braucht und die daher nur dem Spaltenvorrat hinzugefügt werden, so dass der Anwender sie sich bei Bedarf einblenden kann. Mit der Variablen ALV_VARIANT unterstütze ich Layoutvarianten nebst Handle (letzteres ist wichtig, wenn es im Programm mehrere ALVs gibt, damit das System unterscheiden kann, welche Layoutvariante des Reports zu welchem ALV gehört). Ich unterstütze einen eigenen, per SE43 (oder für diejenigen, die pauschal mit der schnarchlahmen SE80 arbeiten, auch damit) anlegbaren Oberflächenstatus, bei dem ich die Standard-ALV-Schaltflächen um eigene erweitere oder - fast noch wichtiger - sinnlose Standardschaltflächen, die man so gut wie bei keinem ALV braucht und die das Ganze nur unübersichtlich machen (ABC-Analyse...), ausblende. Ich reagiere auf Doppelklick auf eine Zeile (im Beispiel damit, dass ich in die Anzeige der gedoppelklickten Personalnummer abspringe). Ich biete das aus Selektionsbildern online dokumentierter Reports bekannte blaue i-Symbol mit Absprung in die Online-Dokumentation des Reports. In dem Abschnitt kann ich auch auf eigene Schaltflächen reagieren.

So ist das für mich ein ALV, das man in einem produktiven Report einem Anwender anbieten kann.

Die OO-basierten Mechaniken können das auch alles; SAP entfernt da keine Funktionalitäten. Insofern bin ich sicher, dass das mit Deiner Methode auch irgendwie gehen wird. Aber nach meiner Erfahrung muss man da ohne Ende Overhead programmieren, Parameter in irgendwelchen Objektattributen und Containerobjekten verstecken usw. Da ich mich mit Deiner Methode nicht auskenne, spiele ich den Ball mal zurück: Wenn Du all das oben von mir Aufgezählte bieten wolltest, wie würde Dein Code dann aussehen? Bin ehrlich neugierig, ob der dann immer noch kurz und übersichtlich ist oder gewaltig anschwillt und/oder schwer nachvollziehbar ist.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
fr-g


Re: Interne Tabelle als ALV

Beitrag von 4byte (Specialist / 124 / 37 / 35 ) »
Hallo zusammen,

um wieder auf die Frage von Lbyte zurück zu kommen:

Beide Möglichkeiten von fr-g und DeathAndPain sind zielführend :up: :up: Welche von beiden du jetzt nutzt bleibt meiner Meinung nach Geschmackssache. Ich verwende oft und gerne die OO Lösung mit CL_SALV_TABLE :D :)
Es gibt 10 Menschen die binär verstehen :)

Re: Interne Tabelle als ALV

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Ein paar Anmerkdungen zu Death&Pains Codeschnipseln
  • Globale Variablen sollten nicht verwendet werden
  • Kopfzeilen schon mal gar nicht
  • Früher habe ich auch die REUSE...-FuBas verwendet. Heutzutage nehme ich statt des REUSE_ALV_GRID_DISPLAY lieber den REUSE_ALV_GRID_DISPLAY_LVC. Funktionell unterscheidet sich das nicht - aber der LVC-FuBa verwendet die Strukturen, die auch die Klasse CL_GUI_ALV_GRID verwendet, so dass man sich nicht merken muss ob das Feld nun "COLWIDTH_OPTIMIZE" ( Reuse) oder "CWIDTH_OPT"( cl_gui_alv_grid ) heißt. Außerdem sind die zugehörigen LVC-Strukturen im DDIC abgelegt und nicht in einer Typgruppe wie bei der REUSE-Version
  • Manuelles Aufbauen eines Feldkatalogs? Ich dachte Programmierer sind faul. Davon abgesehen muss man in dem Fall auch noch die ganzen Übersetzungen mitliefern ( es sei denn man programmiert für eine rein deutsche Firma - soll es ja auch noch geben ). Vorteilhafter erscheint mir das Erstellen eines Feldkatalogs (kann gekapselt und wiederverwendet werden ) und dann manuelle Anpassungen für diejenigen Spalten, die nicht so bleiben sollen wie das System das vorschlägt. Coding hierzu ist nicht groß anders als bei D&P, aber bei Strukturerweiterungen gibt es die gute Chance, dass man hier nichts mehr anpassen muss

    Code: Alles auswählen.

     Feldkatalog lt_fcat erstellen lassen ( z.B. mit LVC_FIELDCATALOG_MERGE oder andere Themen hier im Forum
    loop at lt_fcat assigning ...
    case columname.
    when 'FELDXYZ'.  Besondere Eigenschaften hier setzen
    when 'WEITERES_FELD'. Andere Eigenschaften setzen
    endcase.
    endloop. 
Und noch 2 Anmerkungen zu fr-g.
  • Meines Wissen war die von SAP im Laufe der Jahre empfohlene ALV-Listdarstellung folgende:
    • ganz alt: Die REUSE-Bausteine
    • die Klasse cl_gui_alv_grid ( Objektorientiert )
    • die SALV-Klasse, weil die noch viel mehr auf Objektorientierung setzt
    • aktuell wieder: Die Klasse cl_gui_alv_grid
  • Du fragtest nach den Grenzen des OO-Alv (SALV). Da gibt es einiges. Direkt fällt mir ein, was bei der cl_gui_alv_grid unterstützt wird, beim SALV hingegen nicht mit Bordmitteln sondern nur über Tricksereien, die dann doch beim cl_gui_alv_grid landen:
    • Editierbarkeit von Zellen
    • Kontextmenüs
    • Drag & Drop

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
fr-g

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Interne Tabelle als ALV

Beitrag von Romaniac (Specialist / 198 / 57 / 26 ) »
Ich nutze immer wenn ich nicht editieren muss den SALV:

Code: Alles auswählen.

DATA:
  t_table      TYPE TABLE OF lips,
  r_salv_colsl TYPE REF TO cl_salv_columns_list,
  r_salv_sorts TYPE REF TO cl_salv_sorts.

CALL METHOD cl_salv_table=>factory
  IMPORTING
    r_salv_table = DATA(r_salv)
  CHANGING
    t_table      = t_table.

r_salv->get_columns( )->set_optimize( abap_true ).

* Icon oder Text in der Mitte der Zelle
r_salv_colsl->get_column( 'STATUS_ACC' )->set_alignment( if_salv_c_alignment=>centered ).

* Sort
r_salv_sorts = r_salv->get_sorts( ).
r_salv_sorts->add_sort( columnname = 'AWREF'
                        position = 1 ).
r_salv_sorts->add_sort( columnname = 'GLX_DOCNR'
                        position = 2 ).

PERFORM salv_rename_col USING r_salv_colsl:
  'MESSAGE'       text-mes,
  'VBELN'         text-bel.

r_salv_colsl->set_color_column( 'T_COLOR' ).
r_salv_colsl->set_cell_type_column( 'T_STYLE' ).
r_salv->display( ).


FORM salv_rename_col
  USING iref_alv_cols  TYPE REF TO cl_salv_columns_list
        iv_fieldname   TYPE fieldname
        iv_text        TYPE itex132.

  DATA:
    lref_alv_col TYPE REF TO cl_salv_column_table,
    lref_error   TYPE REF TO cx_root,
    lv_text_s    TYPE scrtext_s,
    lv_text_m    TYPE scrtext_m,
    lv_text_l    TYPE scrtext_l.

  lv_text_l =
  lv_text_m =
  lv_text_s = iv_text.
  TRY.
      lref_alv_col ?= iref_alv_cols->get_column( iv_fieldname ).
    CATCH cx_salv_not_found INTO lref_error.
  ENDTRY.

  IF NOT lref_error IS BOUND.
    TRY.
        lref_alv_col->set_long_text( lv_text_l ).
        lref_alv_col->set_medium_text( lv_text_m ).
        lref_alv_col->set_short_text( lv_text_s ). " --> wenn text( '' ) gesetzt wird und nur langtext mit Spaltenoptimierung
        " dann wird nur der Langtext spaltenoptimiert angezeigt
      CATCH cx_salv_not_found.
    ENDTRY.
  ENDIF.
ENDFORM.
und viele Funktionen mehr die ich ausgelagert habe in Forms(hatte noch keine Zeit um Mehtoden draus zu machen)

Gruß Wolfgang
Geht nicht gibts nicht

Re: Interne Tabelle als ALV

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Globale Variablen sollten nicht verwendet werden
In meinen Augen geht GMV (gesunder Menschenverstand) vor starren Regeln. In echter Logik benutze ich keine globalen Variablen. Ein ALV ist jedoch vergleichbar etwa einem Dynpro (in dem ja von der SAP vorgegebenermaßen auch alles global ist). Von daher sehe ich es entspannt, wenn meine ALV-Ausgabetabelle und deren Layout global ist.

Ansonsten sind bei mir auch Puffertabellen global. Wenn ich auf bestimmte Datensätze einer Tabelle so häufig zugreifen muss, dass ich mir mit einer programmspezifischen Puffertabelle tausende von SELECTs sparen kann (und die Arbeitsspeicherbelastung im Rahmen ist), dann kopiere ich die benötigten Felder mit einem dicken SELECT in eine passende, sortierte Puffertabelle. Die darf dann von überall im Programm anstelle von SELECTs genutzt werden. Auch hier ist die Verständlichkeit gegeben, denn die Tabelle heißt BUFFER_irgendwasSprechendes und wird genau einmal gefüllt, nämlich zum Programmstart. Die dann mit Parametern überall mit durchzureichen, möglicherweise gar über mehrere Etagen verschachtelter Unterprogramme, von denen nur das unterste solch SELECT-Ersatz nutzen möchte, fände ich affig.
Kopfzeilen schon mal gar nicht
Bekanntlich bin ich ein großer Fan von Kopfzeilen und halte die Empfehlung, sie nicht mehr zu nutzen, für eine willkürliche Modeerscheinung. IMHO ist für jeden, der ABAP kann, aus dem Kontext auf einen Blick ersichtlich, ob er eine Kopfzeile oder den Tabellenrumpf vor sich hat, bzw. bei Tabellenrümpfen gebe ich immer explizit [] an (und nutze REFRESH statt CLEAR). Die Anforderungen an das geistige Abstraktionsvermögen, die durch Feldsymbole, funktionale Methoden und Variablenreferenzen, am besten noch in einem Ausdruck geschachtelt, an den Programmierer gestellt werden, sind um Größenordnungen größer als die Arbeit mit Kopfzeilen.

Allerdings geht die Nutzung von Kopfzeilen bei mir in letzter Zeit auch deutlich zurück, weil Feldsymbole und VALUE/CONV sie zunehmend unnötig machen. Wenn ich eine Zeile vor dem APPEND nicht mehr in einer Workarea aufbauen muss, brauche ich keine Kopfzeile. Wenn ich mir per LOOP AT variable ASSIGNING FIELD-SYMBOL(<variable>) en passant eine passende Workarea mit sprechendem Namen beschaffen kann, dann ist das wunderbar, und ich bin nur etwas unglücklich darüber, dass die Winkelklammern um den Variablennamen sich so blöd tippen. Der einst von der SAP bei TABLES gewählte Ansatz, eine zweite Workarea per Stern vor dem Tabellennamen bereitzustellen, erscheint mir bedeutend programmiererfreundlicher und zugleich hervorragend lesbar. Wenn bei jeder Deklaration einer internen Tabelle TABELLENNAME implizit eine Workarea *TABELLENNAME entstehen würde, wäre ich superzufrieden (der eine Stern wäre mir egal), und den Gegnern der Kopfzeile wäre der Wind aus den Segeln genommen. Aber eine zusätzliche Deklarationszeile DATA WA_TABELLENNAME LIKE LINE OF TABELLENNAME ist einfach Codemüll, und der Vorsatz WA_ tippt sich obendrein umständlich und vermindert nach meiner Überzeugung ob seiner Länge die Lesbarkeit des Codes.
Heutzutage nehme ich statt des REUSE_ALV_GRID_DISPLAY lieber den REUSE_ALV_GRID_DISPLAY_LVC.
Ich kann mich erinnern, den auch schon ein paarmal benutzt zu haben, weil er Sachen kann, die der REUSE nicht beherrscht. Das waren aber exotische Sachen, die man nur bei ganz wenigen ALVs braucht, und ich meine mich zu erinnern, dass beim LVC irgendwas umständlicher war. Das kann ich aber nicht belegen, und vielleicht täusche ich mich da auch. Ich bin halt beim REUSE geblieben, weil er perfekt ausreicht und ich halt ein neues ALV schnell per Copy&Paste aus einem Altprogramm hinbekomme (im Prinzip der Code, den ich oben gepostet habe).
Manuelles Aufbauen eines Feldkatalogs? Ich dachte Programmierer sind faul.
Das sind sie; deswegen dokumentiert ja auch niemand. Das ist für mich aber kein Maßstab.
Davon abgesehen muss man in dem Fall auch noch die ganzen Übersetzungen mitliefern ( es sei denn man programmiert für eine rein deutsche Firma - soll es ja auch noch geben ).
Bei einer Firma, in der es komplett international SAPGui-User gibt, die sich in ihrer jeweiligen Landessprache anmelden, hast Du recht. Meine Firma ist auch international tätig, aber da ist die (nicht von mir stammende) Ansage, dass alles, was nicht deutsch ist, mit englisch arbeitet. Ich muss also den Feldkatalog neben deutsch per CASE SY-LANGU auch noch auf englisch bereitstellen, wenn es ein Programm ist, von dem ich nicht genau weiß, dass es nur in Deutschland genutzt werden wird, und dann ist das gut.
Vorteilhafter erscheint mir das Erstellen eines Feldkatalogs (kann gekapselt und wiederverwendet werden ) und dann manuelle Anpassungen für diejenigen Spalten, die nicht so bleiben sollen wie das System das vorschlägt.
Habe ich mir auch schon überlegt, bin dann aber darüber gestolpert, dass ich von 20 Feldern doch 17 umdefinieren musste, und dann lohnt der Fax nicht. Das hängt auch damit zusammen, dass die Bedeutung vieler Felder kontextabhängig ist. Wenn ich beispielsweise eine Liste von Planstellen ausgebe, dann habe ich darin zwei Felder vom Typ PERNR. Die DDIC-Beschreibung "Personalnummer" nützt mir da aber nichts, schon gar nicht doppelt in derselben Liste, sondern die eine Spalte soll mit "Planstelleninhaber" und die andere mit "Führungskraft" überschrieben werden. Bei Feldern, deren Wert ich erst im Programm zusammenbaue (etwa Berechnungsergebnisse), lässt das DDIC mich sowieso im Stich.

Insofern habe ich das mit der DDIC-Unterstützung vor Jahren mal versucht und bin schnell davon abgekommen. Ja, der Aufbau des Feldkatalogs ist eine Fleißarbeit und ja, ich hasse sie, aber wenn ich mit dem Ergebnis zufrieden sein will, gibt es keinen anderen Weg.
Meines Wissen war die von SAP im Laufe der Jahre empfohlene ALV-Listdarstellung folgende:

ganz alt: Die REUSE-Bausteine
die Klasse cl_gui_alv_grid ( Objektorientiert )
die SALV-Klasse, weil die noch viel mehr auf Objektorientierung setzt
aktuell wieder: Die Klasse cl_gui_alv_grid
Schön, dass sogar die SAP mal gemerkt hat, dass Objektorientierung nur um der Objektorientierung willen auch keine Punkte bringt.

Re: Interne Tabelle als ALV

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Romaniac hat geschrieben:

Code: Alles auswählen.

    TRY.
        lref_alv_col->set_long_text( lv_text_l ).
        lref_alv_col->set_medium_text( lv_text_m ).
        lref_alv_col->set_short_text( lv_text_s ). " --> wenn text( '' ) gesetzt wird und nur langtext mit Spaltenoptimierung
        " dann wird nur der Langtext spaltenoptimiert angezeigt
      CATCH cx_salv_not_found.
    ENDTRY.
Dieser Ausschnitt ist ein schönes Beispiel, weshalb ich den Kram nicht mag. Beim Aufbau des Feldkatalogs habe ich eine Struktur, der ich halt die benötigten Werte zuweise und fertig. Hier muss man für jeden einzelnen Wert extra eine Methode aufrufen und das ganze noch über einen TRY-ENDTRY-CATCH-Block absichern, damit einem der Mist nicht dumpen kann. Das finde ich nicht modern, sondern krank.

Re: Interne Tabelle als ALV

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
DeathAndPain hat geschrieben:[...] Ich muss also den Feldkatalog neben deutsch per CASE SY-LANGU auch noch auf englisch bereitstellen,
CASE SY-LANGU und nicht Textsymbole? SLIN wird nie dein Freund werden....
DeathAndPain hat geschrieben:
Vorteilhafter erscheint mir das Erstellen eines Feldkatalogs (kann gekapselt und wiederverwendet werden ) und dann manuelle Anpassungen für diejenigen Spalten, die nicht so bleiben sollen wie das System das vorschlägt.
Habe ich mir auch schon überlegt, bin dann aber darüber gestolpert, dass ich von 20 Feldern doch 17 umdefinieren musste, und dann lohnt der Fax nicht. Das hängt auch damit zusammen, dass die Bedeutung vieler Felder kontextabhängig ist. Wenn ich beispielsweise eine Liste von Planstellen ausgebe, dann habe ich darin zwei Felder vom Typ PERNR. Die DDIC-Beschreibung "Personalnummer" nützt mir da aber nichts, schon gar nicht doppelt in derselben Liste, sondern die eine Spalte soll mit "Planstelleninhaber" und die andere mit "Führungskraft" überschrieben werden. Bei Feldern, deren Wert ich erst im Programm zusammenbaue (etwa Berechnungsergebnisse), lässt das DDIC mich sowieso im Stich.

Insofern habe ich das mit der DDIC-Unterstützung vor Jahren mal versucht und bin schnell davon abgekommen. Ja, der Aufbau des Feldkatalogs ist eine Fleißarbeit und ja, ich hasse sie, aber wenn ich mit dem Ergebnis zufrieden sein will, gibt es keinen anderen Weg.
Das habe ich noch nie gehört. Ich kann mir ja vorstellen, dass eine Spalte mal Planstelleninhaber und mal Führungskraft heißen soll. Und wenn das nur in einem einzigen Report vorkommt kann man ja auch so vorgehen wie du. Aber ich kanngar nicht glauben, dass es nicht noch zig andere Reports gibt, die diese Bezeichnungen auch noch brauchen könnten. Wenn du schon den ganzen Aufwand treibst - warum dann nicht im DDIC Datenelemente anlegen mit den richtigen Bezeichnungen und damit mit Wiederverwendungsmöglichkeit?

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
ralf.wenzel

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Interne Tabelle als ALV

Beitrag von abuma (Specialist / 102 / 36 / 14 ) »
huhu,

also ich persönlich finde salv schon sehr praktisch, gerade auch mit der Feldliste die man nicht selber mühsam aufbauen muss.
Der größte Teil wird somit mit sprechenden Texten, die von der SAP schon in versch. Sprachen gepflegt wurden, befüllt.
Bei einzelnen Spalten die ich anders benennen möchte, mache ich es so wie Romaniac:
Romaniac hat geschrieben:
CODE: ALLES AUSWÄHLEN
TRY.
lref_alv_col->set_long_text( lv_text_l ).
lref_alv_col->set_medium_text( lv_text_m ).
lref_alv_col->set_short_text( lv_text_s ). " --> wenn text( '' ) gesetzt wird und nur langtext mit Spaltenoptimierung
" dann wird nur der Langtext spaltenoptimiert angezeigt
CATCH cx_salv_not_found.
ENDTRY.
Diesen Block kann man ja auch in eine weitere Methode auslagern, so geht das denke ich viel schneller wie das befüllen eines kompletten Feldkatalogs und hat eben den Vorteil der bereits Übersetzten Texte.

Aber natürlich kommt es auch immer auf die Anforderung an, welches ALV man verwenden sollte.
Gerade bei Anforderungen mit Editiermöglichkeit nutze ich die objektorientierte Variante nicht.

Liebe Grüße
abuma

Re: Interne Tabelle als ALV

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
abuma hat geschrieben: also ich persönlich finde salv schon sehr praktisch, gerade auch mit der Feldliste die man nicht selber mühsam aufbauen muss.
Das ist aber kein Alleinstellungsmerkmal des SALV, sondern den automatisierten Aufbau der Feldliste gibt es auch für alle anderen ALV-Versionen. Evtl. muss man einen Fuba/Methode dazu aufrufen, aber häufig genug kann man auf das DDIC referenzieren und alles klappt auch hier automatisch.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Interne Tabelle als ALV

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
DeathAndPain hat geschrieben:
Globale Variablen sollten nicht verwendet werden
In meinen Augen geht GMV (gesunder Menschenverstand) vor starren Regeln. In echter Logik benutze ich keine globalen Variablen. Ein ALV ist jedoch vergleichbar etwa einem Dynpro.
Nein. Ein Dynpro funktioniert nach einem ganz anderes Prinzip als ein ALV, was man schon daran erkennt, dass ein ALV ein Dynpro braucht.
DeathAndPain hat geschrieben:Ansonsten sind bei mir auch Puffertabellen global.
Bei dir vielleicht ;) Ich verwende Klassenattribute (und ja, das ist etwas ganz anderes).
DeathAndPain hat geschrieben:
Kopfzeilen schon mal gar nicht
Bekanntlich bin ich ein großer Fan von Kopfzeilen und halte die Empfehlung, sie nicht mehr zu nutzen, für eine willkürliche Modeerscheinung.
Es ist eher eine willkürliche ABAP-Erscheinung, dass man einen Variablennamen für unterschiedliche Variablen verwendet und man nur deshalb REFRESH erfindet, obwohl ein CLEAR reicht. Eine Tabelle ist für mich eine Variable und die lösche ich mit CLEAR.
DeathAndPain hat geschrieben:LOOP AT variable ASSIGNING FIELD-SYMBOL(<variable>) en passant eine passende Workarea mit sprechendem Namen beschaffen kann, dann ist das wunderbar, und ich bin nur etwas unglücklich darüber, dass die Winkelklammern um den Variablennamen sich so blöd tippen.
Lösung: LOOP AT variable INTO DATA(variable). Ich aber bevorzuge Feldsymbole, weil das schön knallt, wenn es nicht zugewiesen ist, statt einfach nur "leer" zu sein (bei einem LOOP nicht relevant, bei einem READ schon).
DeathAndPain hat geschrieben:Der einst von der SAP bei TABLES gewählte Ansatz, eine zweite Workarea per Stern vor dem Tabellennamen bereitzustellen, erscheint mir bedeutend programmiererfreundlicher und zugleich hervorragend lesbar.
Das und implizite Kopfzeilen sind Dinge, deren Verständnis denen sehr schwer fällt, die aus anderen Programmiersprachen kommen. Das spricht sicher für sich.
Heutzutage nehme ich statt des REUSE_ALV_GRID_DISPLAY lieber den REUSE_ALV_GRID_DISPLAY_LVC.
Ich nutze im Allgemeinen die SALV-Klasse. Das ist am einfachsten zu skalieren, vom Einfachstaufruf (der wirklich sehr einfach ist) bis hin zu sehr komplexem Gedöns.



Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Interne Tabelle als ALV

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
DeathAndPain hat geschrieben:
Romaniac hat geschrieben:

Code: Alles auswählen.

    TRY.
        lref_alv_col->set_long_text( lv_text_l ).
        lref_alv_col->set_medium_text( lv_text_m ).
        lref_alv_col->set_short_text( lv_text_s ). " --> wenn text( '' ) gesetzt wird und nur langtext mit Spaltenoptimierung
        " dann wird nur der Langtext spaltenoptimiert angezeigt
      CATCH cx_salv_not_found.
    ENDTRY.
Dieser Ausschnitt ist ein schönes Beispiel, weshalb ich den Kram nicht mag. Beim Aufbau des Feldkatalogs habe ich eine Struktur, der ich halt die benötigten Werte zuweise und fertig. Hier muss man für jeden einzelnen Wert extra eine Methode aufrufen und das ganze noch über einen TRY-ENDTRY-CATCH-Block absichern, damit einem der Mist nicht dumpen kann.
Nein. Man kann einen großen drumrum bauen nach dem Motto "ich weise jetzt alle Feldeigenschaften zu, wenn (irgend)was dabei schiefgeht, ist das ein Fehler". Man kann mit Ausnahmeklassen irre Sachen machen, wenn man ein bisschen kreativ ist. Früher hab ich die Dinger gehasst wie die Pest, aber seit ich z. B. weiß, wie ich komplette Protokolle durch Verschachteln von Ausnahmen zusammenbauen kann, die ich dann einmal "auspacke" und ins Anwenderlog schreibe (mit einer generischen Klasse, die ich einmal geschrieben habe für das ganze System), bin ich ein echter Fan davon, weil ich dazu nix mehr selbst machen muss.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Vergleichbare Themen

4
Antw.
227
Views
5
Antw.
1247
Views
Inhalt interne Tabelle an andere interne Tabelle übergeben
von L0w-RiDer » 30.01.2020 16:28 • Verfasst in ABAP® für Anfänger
5
Antw.
3004
Views
interne Tabelle in andere interne Tabelle (Format)
von Gast » 20.10.2004 14:44 • Verfasst in ABAP® Core
5
Antw.
303
Views

Aktuelle Forenbeiträge

Zugriff auf Daten via Webdav
vor einer Stunde von msfox 2 / 37
Interne Tabelle
vor 18 Stunden von sap_enthusiast 3 / 163
Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71

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

Zugriff auf Daten via Webdav
vor einer Stunde von msfox 2 / 37
Interne Tabelle
vor 18 Stunden von sap_enthusiast 3 / 163
Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141