Diverse ALV-Probleme
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
Hallo zusammen,
ich hatte vor, EINA/EINE-Daten in einem ALV darzustellen, habe dabei jedoch mehrere Probleme...
Wollte meine Datenstruktur wie folgt aufbauen, damit ich bei der SELECT-Abfrage INTO CORESSPONDING FIELDS nutzen kann:
Probleme: "Es existiert bereits ein Feld mit dem Namen MANDT"
Kann man lösen, indem man folgendes verwendet:
Jedoch stehen dann nach meiner folgenden SQL-Abfrage keine Daten in der internen Tabelle:
-----
Edit: damit ist gemeint, dass die Felder der Strukturen leer sind, obwohl ~2500 Datensätze gefunden werden.
-----
Ich denke, dass bekomme ich ggfs. noch allein gelöst.
Problematischer ist, dass mein Aufbau des Feldkatalogs nicht klappt...
Hab dies einfach wie folgt zu realisieren versucht:
Habe dann einen ABAP Laufzeitfehler bekommen, dass ein Pointer noch nicht gesetzt seu (beim Aufbau des Feldkatalogs).
Wenn ich den Feldkatalog nicht aufbaue, kommt natürlich beim ALV-Aufruf ein Fehler, dass kein Feldkatalog vorhanden ist.
Irgendwie wills heute nicht laufen und ich würde freuen, wenn mir jemand weiterhelfen kann.
Grundsätzliche Vorschläge zu der Vorgehensweise/dem Coding sind auch gerne gesehen.
viele Grüße
Kevin
ich hatte vor, EINA/EINE-Daten in einem ALV darzustellen, habe dabei jedoch mehrere Probleme...
Wollte meine Datenstruktur wie folgt aufbauen, damit ich bei der SELECT-Abfrage INTO CORESSPONDING FIELDS nutzen kann:
Code: Alles auswählen.
Types: begin of tt_data.
INCLUDE STRUCTURE EINA AS EINA.
INCLUDE STRUCTURE EINE as eine.
TYPES: mtart type mara-mtart,
end of tt_data.Kann man lösen, indem man folgendes verwendet:
Code: Alles auswählen.
Types: begin of tt_data
t_eina type eina,
t_eine type eine,
mtart type mara-mtart,
end of tt_data.Code: Alles auswählen.
SELECT * FROM
EINA as a
Inner Join EINE as b on a~infnr = b~infnr
inner join MARA as c on a~matnr = c~matnr
INTO CORRESPONDING FIELDS OF TABLE IT_DATA
WHERE LIFNR = '0000000001'.Edit: damit ist gemeint, dass die Felder der Strukturen leer sind, obwohl ~2500 Datensätze gefunden werden.
-----
Ich denke, dass bekomme ich ggfs. noch allein gelöst.
Problematischer ist, dass mein Aufbau des Feldkatalogs nicht klappt...
Hab dies einfach wie folgt zu realisieren versucht:
Code: Alles auswählen.
Data: it_fieldcat type STANDARD TABLE OF LVC_s_FCAT.
CALL FUNCTION 'LVC_FIELDCATALOG_MERGE'
EXPORTING
* I_BUFFER_ACTIVE =
I_STRUCTURE_NAME = 'tt_data'
* I_CLIENT_NEVER_DISPLAY = 'X'
* I_BYPASSING_BUFFER =
* I_INTERNAL_TABNAME = 'EINA'
CHANGING
ct_fieldcat = it_fieldcat
EXCEPTIONS
INCONSISTENT_INTERFACE = 1
PROGRAM_ERROR = 2
OTHERS = 3
.
"Aufruf des ALV
CALL METHOD go_grid->set_table_for_first_display
EXPORTING
i_structure_name = 'tt_data'
CHANGING
it_outtab = it_data
it_fieldcatalog = it_fieldcat
.
Wenn ich den Feldkatalog nicht aufbaue, kommt natürlich beim ALV-Aufruf ein Fehler, dass kein Feldkatalog vorhanden ist.
Irgendwie wills heute nicht laufen und ich würde freuen, wenn mir jemand weiterhelfen kann.
Grundsätzliche Vorschläge zu der Vorgehensweise/dem Coding sind auch gerne gesehen.
viele Grüße
Kevin
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
hi!
Der LVC_FIELDCATALOG_MERGE funktioniert meines Wissens nur mit DDIC-Strukturen.
Du hast jetzt mehrere Möglichkeiten:
Der LVC_FIELDCATALOG_MERGE funktioniert meines Wissens nur mit DDIC-Strukturen.
Du hast jetzt mehrere Möglichkeiten:
- Den Feldkatalog selber aufbauen
- Den Feldkatalog von beiden verwendeten Tabellen mittels LVC_FIELDCATALOG_MERGE ermitteln und selbst zusammenfürgen
- Eine eigene Methode Schreiben bei der du die benötigten Daten z.B. per RTTI ermittelst (CL_ABAP_TYPEDESCR und seine Unterklassen)
- Das SALV verwenden, das benötigt nämlich keinen Feldkatalog, da es diesen aus den übergebenen Daten ermitteln (RTTI?)
- Möglich, dass es einen ähnlichen Baustein wie LVC_FIELDCATALOG_MERGE gibt der mit Internen Datenstrukturen zurechtkommt (heißer Tipp: Schau dir die anderen Bausteine an die in derselben Funktionsgruppe wie LVC_FIELDCATALOG_MERGE liegen)
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
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
Hoi adt,
danke für die Rückinfo.
Hab gehofft, der Fuba baut mir den Feldkatalog zusammen, da ich ja nur DDIC-Typen in meiner Struktur verwende.
Werde dann mal versuchen, den selbst zusammenzusetzen...
Weiteres Problem ist dann noch meine SQL-Abfrage, wo er zwar die Datensätze findet, aber nicht in die interne Struktur übernimmt.
Hast du da vielleicht noch eine Idee?
gruß
Edit:
Hiermit bekomme ich zumindest alle EINA-Daten, und zwar auch soviele, wieviele EINE-Datensätze dazu bestehen:
Muss ich dann wohl drüber loopen und die EINE-Daten einzeln nachlesen, oder?
Edit2:
Mein Versuch einen Fieldcat aufzubauen scheint zu klappen, beim Aufruf des ALV's kommts trotzdem zum Kurzdump, wegen eines angeblich nicht zugewiesenen Pointers....
Hier dumpt das Programm dann und ich verstehe nicht wieso:
Habe jedoch folgende Theorie:
Tabelle EINA hat 38 Felder, EINE hat 73, ergibt insgesamt 111 Felder.
Seltsamerweise hat mein Fieldcatalog nur 109 Einträge, ich tippe, dass er für MANDT/INFNR, die in beiden Tabellen vorkommen nicht nochmal einen Eintrag erstellt und es dadran hängt :/
Kann ich das irgendwie umgehen?
danke für die Rückinfo.
Hab gehofft, der Fuba baut mir den Feldkatalog zusammen, da ich ja nur DDIC-Typen in meiner Struktur verwende.
Werde dann mal versuchen, den selbst zusammenzusetzen...
Weiteres Problem ist dann noch meine SQL-Abfrage, wo er zwar die Datensätze findet, aber nicht in die interne Struktur übernimmt.
Hast du da vielleicht noch eine Idee?
gruß
Edit:
Hiermit bekomme ich zumindest alle EINA-Daten, und zwar auch soviele, wieviele EINE-Datensätze dazu bestehen:
Code: Alles auswählen.
SELECT *
FROM EINA as a Inner Join eine as b on a~infnr = b~infnr
inner join mara as c on a~matnr = c~matnr
INTO CORRESPONDING FIELDS of wa_DATA-t_eina
WHERE LIFNR = '0000000001'.
append wa_data to it_data.
endselect.Edit2:
Mein Versuch einen Fieldcat aufzubauen scheint zu klappen, beim Aufruf des ALV's kommts trotzdem zum Kurzdump, wegen eines angeblich nicht zugewiesenen Pointers....
Code: Alles auswählen.
Types: begin of tt_data,
t_eina type EINA,
t_eine type eine,
end of tt_data.
DATA: ok_code LIKE sy-ucomm,
it_data Type Table of tt_data,
wa_data like line of it_data,
it_fieldcat type LVC_T_FCAT,
it_fieldcat2 type lvc_t_fcat,
wa_fieldcat like line of it_fieldcat.
CALL FUNCTION 'LVC_FIELDCATALOG_MERGE'
EXPORTING
* I_BUFFER_ACTIVE =
I_STRUCTURE_NAME = 'EINA'
* I_CLIENT_NEVER_DISPLAY = 'X'
* I_BYPASSING_BUFFER =
* I_INTERNAL_TABNAME = 'EINA'
CHANGING
ct_fieldcat = it_fieldcat
EXCEPTIONS
INCONSISTENT_INTERFACE = 1
PROGRAM_ERROR = 2
OTHERS = 3
.
IF sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
clear it_fieldcat2.
CALL FUNCTION 'LVC_FIELDCATALOG_MERGE'
EXPORTING
* I_BUFFER_ACTIVE =
I_STRUCTURE_NAME = 'EINE'
* I_CLIENT_NEVER_DISPLAY = 'X'
* I_BYPASSING_BUFFER =
* I_INTERNAL_TABNAME = 'EINE'
CHANGING
ct_fieldcat = it_fieldcat2
EXCEPTIONS
INCONSISTENT_INTERFACE = 1
PROGRAM_ERROR = 2
OTHERS = 3
.
IF sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
loop at it_fieldcat2 into wa_fieldcat.
append wa_fieldcat to it_fieldcat.
endloop.Code: Alles auswählen.
CALL METHOD go_grid->set_table_for_first_display
* EXPORTING
CHANGING
it_outtab = it_data
it_fieldcatalog = it_fieldcat
EXCEPTIONS
invalid_parameter_combination = 1
program_error = 2
too_many_lines = 3
others = 4
.
IF sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.Tabelle EINA hat 38 Felder, EINE hat 73, ergibt insgesamt 111 Felder.
Seltsamerweise hat mein Fieldcatalog nur 109 Einträge, ich tippe, dass er für MANDT/INFNR, die in beiden Tabellen vorkommen nicht nochmal einen Eintrag erstellt und es dadran hängt :/
Kann ich das irgendwie umgehen?
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Beide Fehler haben dieselbe Ursache:
Darfst bei deiner Struktur keine FELDER vom Typ EINE oder EINA anlegen, sondern du musst mit INCLUDE TYPE arbeiten.
Nur so funktioniert das INTO CORRESPONDING FIELDS da es per NAME geht. Das MANDT-Feld zu EINA in deiner Struktur heißt zum Beispiel derzeit eigentlich T_EINA-MANDT. Deswegen auch der Pointer-Fehler im ALV.
Was du vorhast funktioniert so nicht
So leid es mir tut, du wirst dir wohl oder übel eine neue Struktur für die Abfrage und Anzeige basteln müssen.
Entweder statisch
Oder dynamisch mit RTTI/RTTC
Schau dir zu dem Thema folgende Dinge genauer an:
lg ADT
---EDIT---
Sry, hab bei deinem ersten Post überlesen, das du die Sache mit dem INCLUDE bereits "umgangen" hast.
Darfst bei deiner Struktur keine FELDER vom Typ EINE oder EINA anlegen, sondern du musst mit INCLUDE TYPE arbeiten.
Nur so funktioniert das INTO CORRESPONDING FIELDS da es per NAME geht. Das MANDT-Feld zu EINA in deiner Struktur heißt zum Beispiel derzeit eigentlich T_EINA-MANDT. Deswegen auch der Pointer-Fehler im ALV.
Was du vorhast funktioniert so nicht
So leid es mir tut, du wirst dir wohl oder übel eine neue Struktur für die Abfrage und Anzeige basteln müssen.
Entweder statisch
Oder dynamisch mit RTTI/RTTC
Schau dir zu dem Thema folgende Dinge genauer an:
- Befehl CREATE DATA ... TYPE HANDLE ...
- Befehl ASSIGN ...->* TO
- Klasse CL_ABAP_TYPEDESCR und die Subklassen
- Klasse CL_SALV_TABLE
lg ADT
---EDIT---
Sry, hab bei deinem ersten Post überlesen, das du die Sache mit dem INCLUDE bereits "umgangen" hast.
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
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
Wäre ja auch zu schön gewesena-dead-trousers hat geschrieben:Beide Fehler haben dieselbe Ursache:
Darfst bei deiner Struktur keine FELDER vom Typ EINE oder EINA anlegen, sondern du musst mit INCLUDE TYPE arbeiten.
Nur so funktioniert das INTO CORRESPONDING FIELDS da es per NAME geht und das MANDT-Feld zu EINA in deiner Struktur heißt derzeit eigentlich T_EINA-MANDT. Deswegen auch der Pointer-Fehler im ALV.
Was du vorhast funktioniert so nicht
Code: Alles auswählen.
Types: begin of tt_data.
include structure eina as t_eina.
include structure eine as t_eine.
types: end of tt_data.Code: Alles auswählen.
Types: begin of tt_data.
include type eina as t_eina.
include type eine as t_eine.
types: end of tt_data.Brauche ich die 4 aufgeführten Punkte von dir auch, wenn ich einen SALV verwende?So leid es mir tut, du wirst dir wohl oder über eine neue Struktur für die Abfrage und Anzeige basteln müssen.
Entweder statisch
Oder dynamisch mit RTTI/RTTC
Schau dir zu dem Thema folgende Dinge genauer an:Den SALV würd ich dir deswegen wärmstens empfehlen, da du dann die Sache mit dem Feldkatalog nicht mehr brauchst.
- Befehl CREATE DATA ... TYPE HANDLE ...
- Befehl ASSIGN ...->* TO
- Klasse CL_ABAP_TYPEDESCR und die Subklassen
- Klasse CL_SALV_TABLE
lg ADT
Wollte nämlich gerne bei dem ALV-Grid bleiben, da meines Wissens der SALV weniger Funktionen bietet, das werde ich mir aber nochmal anschauen...
Werde es dann mal testen, meine itab
Code: Alles auswählen.
Types: begin of tt_data.
t_eina type eina,
t_eine type eine,
end of tt_data.Statisch will ich das nur sehr ungern machen, da ich ja nicht sicher sein kann, dass die Struktur von EINA/EINE nicht noch erweitert wird.
Btw: Habe vorhin mir mal nur eine it_data type table of eina aufgebaut, dort Daten reingeladen, mittels 'REUSE_ALV_FIELDCATALOG_MERGE' meinen Feldkatalog aufgebaut, diesen über 'LVC_TRANSFER_FROM_SLIS' gewandelt und an den ALV übergeben.
SAP beginnt tatsächlich, den ALV aufzubauen, bevor es zu einem Kurzdump kommt, der aber sehr nach SAP-Basis Problem klingt (Kommunikationsproblem).
Danke für deine Hilfe adt!
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Hier Schnell-Zusammenfassung wie man mit RTTI/RTTC eine dynamische Tabelle aufbaut:
Ein Zugriff auf einzelne Componenten ist übrigens nur mittels ASSIGN COMPONENT ... OF STRUCTURE möglich!
- Mit der Methode CL_ABAP_TYPEDESCR=>DESCRIBE_BY_NAME( '...' ) erhällt man einen CL_ABAP_STRUCTDESCR.
- Um ihn verwenden zu können musst du mittels ?= Casten!!!
- Mit der Methode CL_ABAP_STRUCTDESCR=>GET_COMPONENTS( ) kannst du alle Felder auslesen.
- Das machst du 2mal (EINA und EINE) und fügst beide Ergnisse zusammen.
- Dann sortieren und doppelte Einträge rauswerfen
- Mit CL_ABAP_STRUCTDESCR=>CREATE( ... ) daraus eine Strukturbeschreibung erstellen
- Mit CL_ABAP_TABLEDESCR=>CREATE( ... ) daraus eine Tabellebeschreibung erstellen
- Mit CREATE DATA ... TYPE HANDLE ... eine Variable anlegen
- Mit ASSIGN ...->* TO ... der Variable einem Feldsymbol zuweisen
Ein Zugriff auf einzelne Componenten ist übrigens nur mittels ASSIGN COMPONENT ... OF STRUCTURE möglich!
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
km216
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
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
Danke adt, ich schaue mal, wie ich damit klarkomme 
Ich denke, den Schritt mit einer dynamischen Tabelle muss ich so oder so gehen, denn:
Neben den kompletten Daten aus EINA/EINE sollen noch die Konditionen ausgelesen werden.
Daran komme ich ja mittels A017/A018 für die Infosätze, sowie etlichen weiteren Tabellen (Lieferanten- und Warengruppenkonditionen) und dann KONH, KONP, KONM und KONW.
Da ich die Konditionen, die zum Infosatz/Lieferant vorhanden sind, in der gleichen Zeile unterbringen will, muss ich meine Tabelle nach der Selektion so oder so dynamisch um eine Spalte für die jeweilige Konditionsart erweitern.
Zwei weitere Fragen habe ich jedoch noch...
Würdet ihr mir für die Definition des Selektionsbildes zu einem klassischen Selection Screen raten, oder sollte ich mir dieses mittels eines Dynpros im Screen-Painter zusammenbauen?
Was sind die gröbsten Unterschiede zwischen Alv Grid (OO) und SALV?
Abgesehen davon, dass ich beim SALV keinen Feldkatalog brauche. Habe auf die Schnelle leider nichts brauchbares zu den Unterschieden gefunden, suche aber noch weiter
Edit:
Folgendes habe ich herausgefunden: Layouts und Export an Excel sollte beim SALV auch gehen, dass sind nämlich Funktionen, die ich auf jeden Fall brauche.
Ich denke, den Schritt mit einer dynamischen Tabelle muss ich so oder so gehen, denn:
Neben den kompletten Daten aus EINA/EINE sollen noch die Konditionen ausgelesen werden.
Daran komme ich ja mittels A017/A018 für die Infosätze, sowie etlichen weiteren Tabellen (Lieferanten- und Warengruppenkonditionen) und dann KONH, KONP, KONM und KONW.
Da ich die Konditionen, die zum Infosatz/Lieferant vorhanden sind, in der gleichen Zeile unterbringen will, muss ich meine Tabelle nach der Selektion so oder so dynamisch um eine Spalte für die jeweilige Konditionsart erweitern.
Zwei weitere Fragen habe ich jedoch noch...
Würdet ihr mir für die Definition des Selektionsbildes zu einem klassischen Selection Screen raten, oder sollte ich mir dieses mittels eines Dynpros im Screen-Painter zusammenbauen?
Was sind die gröbsten Unterschiede zwischen Alv Grid (OO) und SALV?
Abgesehen davon, dass ich beim SALV keinen Feldkatalog brauche. Habe auf die Schnelle leider nichts brauchbares zu den Unterschieden gefunden, suche aber noch weiter
Edit:
Folgendes habe ich herausgefunden: Layouts und Export an Excel sollte beim SALV auch gehen, dass sind nämlich Funktionen, die ich auf jeden Fall brauche.
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
hi!
SALV ist nichts anderes als ein ALV mit einer vollständigen OO-Schale drumherum.
(Wenn man sich in den zugehörigen Klassen ganz nach unten durchgräbt findet man ALV, Fieldcat und co. wieder)
Das einzige was SALV im Gegensatz zum reinen ALV nicht kann, ist die angezeigten Daten zu editieren.
Das geht definitiv nicht und ist ja auch beim ALV nur recht "halbherzig" implementiert worden.
Also kurz die Vor- und Nachteile des SALV:
+ Kein Feldkatalog erstellen notwendig
+ Kein Ausgabedynpro notwendig (Fullscreen-Ausgabe, ohne Container)
+ Kann ohne viel Aufwand auch in bestehende Dynpros integriert werden (Entweder in vorhandenem CL_GUI_CONTAINER oder direkt per CONTAINER_NAME)
+ Keine Unterscheidung notwendig ob GUI vorhanden ist oder nicht (z.B. Batch-Modus). Es wird selbständig in ALV List umgeschalten.
+ Für eine schnelle Ausgabe (ohne besondere Einstellungen) sind nur zwei Befehle und ein Parameter (Tabelle) notwendig: FACTORY und DISPLAY
- Keine Editierfunktionen
- Das OO-Interface ist für Anfänger (und ABAP/4 Programmierer) die bislang nichts mit Klassen gemacht haben gewöhnungsbedürftig.
Ich würde für den Anfang einen Selektionscreen empfehlen wenns zu aufwändig wird, kannst ja immer noch ein eigenen Dynpro schreiben.
lg ADT
SALV ist nichts anderes als ein ALV mit einer vollständigen OO-Schale drumherum.
(Wenn man sich in den zugehörigen Klassen ganz nach unten durchgräbt findet man ALV, Fieldcat und co. wieder)
Das einzige was SALV im Gegensatz zum reinen ALV nicht kann, ist die angezeigten Daten zu editieren.
Das geht definitiv nicht und ist ja auch beim ALV nur recht "halbherzig" implementiert worden.
Also kurz die Vor- und Nachteile des SALV:
+ Kein Feldkatalog erstellen notwendig
+ Kein Ausgabedynpro notwendig (Fullscreen-Ausgabe, ohne Container)
+ Kann ohne viel Aufwand auch in bestehende Dynpros integriert werden (Entweder in vorhandenem CL_GUI_CONTAINER oder direkt per CONTAINER_NAME)
+ Keine Unterscheidung notwendig ob GUI vorhanden ist oder nicht (z.B. Batch-Modus). Es wird selbständig in ALV List umgeschalten.
+ Für eine schnelle Ausgabe (ohne besondere Einstellungen) sind nur zwei Befehle und ein Parameter (Tabelle) notwendig: FACTORY und DISPLAY
- Keine Editierfunktionen
- Das OO-Interface ist für Anfänger (und ABAP/4 Programmierer) die bislang nichts mit Klassen gemacht haben gewöhnungsbedürftig.
Ich würde für den Anfang einen Selektionscreen empfehlen wenns zu aufwändig wird, kannst ja immer noch ein eigenen Dynpro schreiben.
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
km216
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
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
Da die Daten nach Excel gezogen, dort editiert und dann wieder importiert werden sollen, ist das für mich auch nicht nötig.a-dead-trousers hat geschrieben:Das einzige was SALV im Gegensatz zum reinen ALV nicht kann, ist die angezeigten Daten zu editieren.
Das geht definitiv nicht und ist ja auch beim ALV nur recht "halbherzig" implementiert worden.
Da wir an der Uni mit Java programmieren müssen und meine einzige ABAP-Schulung (ohne jeglichen vorherigen Kenntnisse) eine 3 Tage ABAP OO-Schulung war, komme ich damit hoffentlich zurechta-dead-trousers hat geschrieben: - Das OO-Interface ist für Anfänger (und ABAP/4 Programmierer) die bislang nichts mit Klassen gemacht haben gewöhnungsbedürftig.
Danke nochmal für die ausführliche Antwort!
Also, ich bin jetzt etwas weiter, habe den SALV ausprobiert.
Was mich dort stört:
-selbst wenn ich alle Funktionen einblende, sind dies weniger als beim ALV_Grid.
- der Export nach Excel sieht beim ALV_Grid besser aus, beim SALV werden noch zusätzliche Daten hinzugefügt, was ich nicht möchte ("09.09.2011 Dynamische Listenausgabe 1")
- zwischen Spaltenüberschriften und Daten ist eine Leerzeile, die mich ebenfalls stört
2 weitere Fragen drängen sich mir daher beim SALV bzw. ALV Grid auf:
- Lässt sich die Überschrift der Spalten anpassen?
-> sollte beim ALV Grid über den Fieldcatalog gehen, wie ist es beim SALV?
- wenn ich meine interne Tabelle komplett dynamisch aufbaue, können die Anwender dann Layout-Varianten der Darstellung speichern? Oder geht dies nicht, da die Tabelle jedesmal anders aufgebaut sein kann?
Gruß
Was mich dort stört:
-selbst wenn ich alle Funktionen einblende, sind dies weniger als beim ALV_Grid.
- der Export nach Excel sieht beim ALV_Grid besser aus, beim SALV werden noch zusätzliche Daten hinzugefügt, was ich nicht möchte ("09.09.2011 Dynamische Listenausgabe 1")
- zwischen Spaltenüberschriften und Daten ist eine Leerzeile, die mich ebenfalls stört
2 weitere Fragen drängen sich mir daher beim SALV bzw. ALV Grid auf:
- Lässt sich die Überschrift der Spalten anpassen?
-> sollte beim ALV Grid über den Fieldcatalog gehen, wie ist es beim SALV?
- wenn ich meine interne Tabelle komplett dynamisch aufbaue, können die Anwender dann Layout-Varianten der Darstellung speichern? Oder geht dies nicht, da die Tabelle jedesmal anders aufgebaut sein kann?
Gruß
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
hi!
Mit GET_COLUMNS bzw. GET_FUNCTIONS erhälltst du jeweils ein Objekt mit dem du die Spalten bzw. die Funktionen die angezeigt werden bearbeiten kannt.
Mit CL_SALV_COLUMNS_TABLE=>GET_COLUMN kannst du die einzelnen Spalten ansprechen und bearbeiten. Schau dir unbedingt auch die Subklassen von CL_SALV_COLUMN durch, da sie je nach Anzeigewerkzeug (Tree/Table) unterschiedliche Funktionen bieten (ungefähr so wie CL_GUI_ALV_TREE und CL_GUI_ALV_TABLE in Bezug auf den Feldkatalog)
Mit GET_TOP_OF_LIST_PRINT kannst du die Kopfzeile im Ausdruck(Export?) bearbeiten, mit GET_PRINT den Ausdruck selbst usw.
Schau dir einfach die ganzen Methoden von CL_SALV_TABLE durch. Ich glaub damit sollten (fast) alle deine Problem beseitigt werden können.
Mit einer einzigen Ausnahme: Das Speichern von Layouts zu dynamisch erstellten Strukturen (die sich vorraussichtlich immer ändern werden!) ist zwar möglich, aber wird nichts nutzen, denn sobald sich die Spalten ändern, passt der Feldkatalog nicht mehr zusammen. Ist ja, wenn man es genau betrachtet, eher sinnlos sich irgendwo statisch etwas zu merken, was sich jederzeit dynamisch ändern kann.
Wenn du zwar dynamische Strukturen verwendest, die aber auf, sagen wir mal, Datenbanktabellen basieren dann dürften die Layouts wiederum kein Problem machen, denn DB-Tabellen werden sich nicht so schnell ändern Du muss dir halt nur einen Mechanismus überlegen wie du mehrere Layouts innerhalb eines Programms verwaltest. Beim ALV konnte man ja eine laufende Nummer vergeben, ich hab das dann immer so gemacht:
Wenn Tabelle A, B und C dann Nummer 1
Wenn Tabelle A und C dann Nummer 2
Wenn Tabelle D, und F dann Nummer 3
usw.
Das müsse auch beim SALV funktionieren, musst nur halt ausprobieren.
---EDIT---
CL_SALV_TABLE->GET_LAYOUT und CL_SALV_LAYOUT->SET_KEY sollten das sein was du in dem Fall brauchst
-----------
lg ADT
Mit GET_COLUMNS bzw. GET_FUNCTIONS erhälltst du jeweils ein Objekt mit dem du die Spalten bzw. die Funktionen die angezeigt werden bearbeiten kannt.
Mit CL_SALV_COLUMNS_TABLE=>GET_COLUMN kannst du die einzelnen Spalten ansprechen und bearbeiten. Schau dir unbedingt auch die Subklassen von CL_SALV_COLUMN durch, da sie je nach Anzeigewerkzeug (Tree/Table) unterschiedliche Funktionen bieten (ungefähr so wie CL_GUI_ALV_TREE und CL_GUI_ALV_TABLE in Bezug auf den Feldkatalog)
Mit GET_TOP_OF_LIST_PRINT kannst du die Kopfzeile im Ausdruck(Export?) bearbeiten, mit GET_PRINT den Ausdruck selbst usw.
Schau dir einfach die ganzen Methoden von CL_SALV_TABLE durch. Ich glaub damit sollten (fast) alle deine Problem beseitigt werden können.
Mit einer einzigen Ausnahme: Das Speichern von Layouts zu dynamisch erstellten Strukturen (die sich vorraussichtlich immer ändern werden!) ist zwar möglich, aber wird nichts nutzen, denn sobald sich die Spalten ändern, passt der Feldkatalog nicht mehr zusammen. Ist ja, wenn man es genau betrachtet, eher sinnlos sich irgendwo statisch etwas zu merken, was sich jederzeit dynamisch ändern kann.
Wenn du zwar dynamische Strukturen verwendest, die aber auf, sagen wir mal, Datenbanktabellen basieren dann dürften die Layouts wiederum kein Problem machen, denn DB-Tabellen werden sich nicht so schnell ändern
Du muss dir halt nur einen Mechanismus überlegen wie du mehrere Layouts innerhalb eines Programms verwaltest. Beim ALV konnte man ja eine laufende Nummer vergeben, ich hab das dann immer so gemacht:Wenn Tabelle A, B und C dann Nummer 1
Wenn Tabelle A und C dann Nummer 2
Wenn Tabelle D, und F dann Nummer 3
usw.
Das müsse auch beim SALV funktionieren, musst nur halt ausprobieren.
---EDIT---
CL_SALV_TABLE->GET_LAYOUT und CL_SALV_LAYOUT->SET_KEY sollten das sein was du in dem Fall brauchst
-----------
lg ADT
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
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
Nochmal Danke adt.
Habe einfach mal bissl was hingecodet und es tatsächlich zum laufen bekommen (dynamische Erzeugung einer internen Tabelle vom Typ wie EINA, der Schritt zur Verknüpfung mit EINE ist ja dann nicht mehr weit)
Falls es jemand interessiert, hier der Code:
<fs_data> enthält dann die gewünschten Daten.
Nun habe ich aber noch eine Frage zu folgendem Satz:
Wie kann ich dies realisieren? ich weiß ja vorher nicht, wie die heißen
In meiner internen Tabelle it_components stehen ja noch die Namen der Spalten drin, wo ich aber auch vorher nicht weiß, welche das sind...
Kann ich irgendwie die Spalten durchloopen?
Edit:
gelöst
Musste <fs_data> von table auf standard table ändern, da ich nur erstmal den ersten Datensatz ausgeben wollte und Indexzugriff bei Standard Table funktioniert
Ausgabe des ersten Datensatzes:
Habe einfach mal bissl was hingecodet und es tatsächlich zum laufen bekommen (dynamische Erzeugung einer internen Tabelle vom Typ wie EINA, der Schritt zur Verknüpfung mit EINE ist ja dann nicht mehr weit)
Falls es jemand interessiert, hier der Code:
Code: Alles auswählen.
DATA: lr_typedescr_ref TYPE REF TO cl_abap_typedescr,
lr_strucdescr_ref TYPE REF TO cl_abap_structdescr,
lr_tabledescr_ref type ref to cl_abap_tabledescr,
lr_datadescr_ref type ref to cl_abap_datadescr,
it_components TYPE cl_abap_structdescr=>component_table,
lr_data type ref to data.
FIELD-SYMBOLS: <fs_components> LIKE LINE OF it_components,
<fs_data> type any table.
lr_typedescr_ref = cl_abap_typedescr=>describe_by_name( 'EINA' ).
lr_strucdescr_ref ?= lr_typedescr_ref.
it_components = lr_strucdescr_ref->get_components( ).
TRY.
CALL METHOD cl_abap_structdescr=>create
EXPORTING
p_components = it_components
* p_strict = TRUE
receiving
p_result = lr_strucdescr_ref
.
CATCH cx_sy_struct_creation .
ENDTRY.
TRY.
CALL METHOD cl_abap_tabledescr=>create
EXPORTING
p_line_type = lr_strucdescr_ref
* p_table_kind = TABLEKIND_STD
* p_unique = ABAP_FALSE
* p_key =
* p_key_kind = KEYDEFKIND_DEFAULT
receiving
p_result = lr_tabledescr_ref
.
CATCH cx_sy_table_creation .
ENDTRY.
CREATE DATA lr_data TYPE HANDLE lr_tabledescr_ref.
assign lr_data->* to <fs_data>.
SELECT *
FROM eina AS a
INNER JOIN eine AS b ON a~infnr = b~infnr
INTO CORRESPONDING FIELDS OF table <fs_data>
WHERE lifnr = '0000000001'.
Nun habe ich aber noch eine Frage zu folgendem Satz:
Du meinst damit doch das ansprechen der einzelnen Spalten meiner Tabelle, oder?a-dead-trousers hat geschrieben: Ein Zugriff auf einzelne Componenten ist übrigens nur mittels ASSIGN COMPONENT ... OF STRUCTURE möglich!
Wie kann ich dies realisieren? ich weiß ja vorher nicht, wie die heißen
In meiner internen Tabelle it_components stehen ja noch die Namen der Spalten drin, wo ich aber auch vorher nicht weiß, welche das sind...
Kann ich irgendwie die Spalten durchloopen?
Edit:
gelöst
Musste <fs_data> von table auf standard table ändern, da ich nur erstmal den ersten Datensatz ausgeben wollte und Indexzugriff bei Standard Table funktioniert
Code: Alles auswählen.
<fs_data> type standard table,
<fs_datensatz> type any,
<fs_daten> type any.Code: Alles auswählen.
read table <fs_data> index 1 assigning <fs_datensatz>.
WHILE sy-subrc = 0.
ASSIGN COMPONENT sy-index OF STRUCTURE <fs_datensatz> TO <fs_daten>.
write <fs_daten>.
endwhile.
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
hi!
Oder:
Dann kannst dir den Namen uU auch noch mitausgeben lassen
lg ADT
Oder:
Code: Alles auswählen.
loop at it_components assigning <fs_components>.
assign component <fs_components>-name of structure <fs_datensatz> TO <fs_daten>.
...
endloop.lg ADT
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
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
hi adt,
Danke für den Tip.
An die Namen zu kommen ist jedoch nicht so das Problem, die stehen ja auch schön ordentlich in einer Spalte meiner internen Tabelle it_components, da brauch ich dann nicht einmal Field-Symbols
Danke für den Tip.
An die Namen zu kommen ist jedoch nicht so das Problem, die stehen ja auch schön ordentlich in einer Spalte meiner internen Tabelle it_components, da brauch ich dann nicht einmal Field-Symbols
Beitrag
von rafaelvives (ForumUser / 25 / 2 /
0
)
»
Hallo,
Dein Ticket ist was lange her....
Dennoch mich würde interessieren woher die Zeile " Datum.... Dynamische Listenausgabe" stammt.
Danke im Voraus für den Tipp...
Raf
Dein Ticket ist was lange her....
Dennoch
mich würde interessieren woher die Zeile " Datum.... Dynamische Listenausgabe" stammt.Danke im Voraus für den Tipp...
Raf
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
2442
Views
Views
4
Antw.
Antw.
568
Views
Views
1
Antw.
Antw.
353
Views
Views
Diverse Fragen zu Oberflächentexten
von Kudert777 » 14.07.2020 17:56 • Verfasst in ABAP® für Anfänger
von Kudert777 » 14.07.2020 17:56 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
11129
Views
Views
Bestellung via Mail an diverse Mail-Adressen
von Rabea1103 » 18.01.2012 15:12 • Verfasst in Material Management & Produktionsplanung
von Rabea1103 » 18.01.2012 15:12 • Verfasst in Material Management & Produktionsplanung
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 14 Stunden von ralf.wenzel 104 / 10122
vor 14 Stunden von ralf.wenzel 104 / 10122
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 14 Stunden von ralf.wenzel 104 / 10122
vor 14 Stunden von ralf.wenzel 104 / 10122