Farbe mit lvc_t_scol definieren

Re: Farbe mit lvc_t_scol definieren

Deine Tabelle muss eine Spalte haben, die nicht Teil der im ALV darzustellenden Spalten ist, sondern in der Du den gewünschten Farbwert hinterlegst. Mit der Methode SET_COLOR_COLUMN Deines Objektes der Klasse CL_SALV_COLUMNS_TABLE (das Du mit CL_SALV_TABLE->GET_COLUMNS erhalten hast) teilst Du dem ALV den Spaltennamen fest, den Du Deiner Farbspalte gegeben hast, damit es die Spalte entsprechend auswerten kann.

Re: Farbe mit lvc_t_scol definieren

Demo-Report BCALV_TEST_COLORS

Re: Farbe mit lvc_t_scol definieren

Vielen Danke für die schnellen Antworten, mit lvc_s_colo statt lvc_t_scol hat es geklappt.

Re: Farbe mit lvc_t_scol definieren

Aber die Felder sind doch alle Integer-Typen :P
Ich hatte das oben schon mit VALUE vorformuliert.

Re: Farbe mit lvc_t_scol definieren

DeathAndPain hat geschrieben: ↑

08.12.2020 14:08

Code: Alles auswählen.

LEAVE TO SCREEN 0.

obgleich Dynpronummern immer NUMCs sind und daher (zur Vermeidung einer überflüssigen Konvertierung) in Anführungszeichen geschrieben werden sollten.

Guter Hinweis! Das habe ich noch nie beachtet.

Re: Farbe mit lvc_t_scol definieren

Dynpronummern sind nicht immer vom Typ NUMC sondern manchmal auch vom Typ CHAR ( SY-DYNNR ).

Du hast recht. Sorry für diese Ungenauigkeit auf meiner Seite.

Zweitens: Könntest du bitte mal einen Link zu deiner Behauptung posten der erklärt welche Konvertierungen bei der Zuweisung einer Zahl zu einem NUMC-Feld passieren die bei einer Zuweisung eines Char-Felds zu einem NUMC-Feld nicht passieren und dass das tatsächlich ( von mir aus auch nur marginal ) schneller ist.

Ein NUMC-Feld ist (wie das C in "NUMC" schon sagt), technisch gesehen ein Characterfeld. Dasselbe gilt übrigens auch für Datumsfelder, nur dass ABAP bei Zuweisungen bei NUMC-Feldern prüft, ob man da nur Zahlen reinschreibt, wohingegen man in ein Feld vom Typ D (bzw. DATS) jeden Character-Unsinn reinschreiben kann.

Bei einer Zuweisung einer Zahl zu einem NUMC-Feld muss diese technisch gewandelt werden. Bei einer CHAR-Quelle ist hingegen nur eine Prüfung nötig, ob die Stellen auch alle Ziffern sind. Ggf. wird mit Nullen aufgefüllt, da hast Du recht. Wenn das zugewiesene Feld aber formal dem NUMC-Standard entspricht, ist nichts zu tun. Von daher liegt es auf der Hand, dass der Aufwand hier geringer ist.

Und nein, ich habe die Performance nicht gemessen, und ich behaupte, Du auch nicht. Ich rechne auch nicht mit einer in der Höhe nennenswerten Auswirkung auf die Performance, auch wenn ich davon ausgehe, dass es einen Unterschied geben wird. Für mich symbolisiert es aber mangelnde Bewusstheit hinsichtlich der Datentypen, wenn man einem als NUMC (oder hier sogar als CHAR) definierten Feld eine Integerzahl als Literal zuweist. Literale sollten meiner Meinung nach immer in dem Datentyp abgefasst werden, dem sie zugeordnet werden.

Wobei die Frage spannend ist, ob die Dynpronummer bei LEAVE TO SCREEN x (oder CALL SCREEN x) technisch als NUMC oder als CHAR implementiert ist. Du hast recht, dass SY-DYNNR etwas inkonsequent als CHAR umgesetzt worden ist. Aber wenn die o.g. Befehle den Wert als CHAR interpretieren würden, dann würde ein LEAVE TO SCREEN 0. ja sogar die Null in die dritte Stelle des vierstelligen Characterfeldes setzen (rechtsbündig, aber mit nachfolgendem Vorzeichen, wie ABAP das halt so macht, wenn man eine Integerzahl einem C-Feld zuweist). Das dürfte dann eigentlich nicht funktionieren. Also ist davon auszugehen, dass das intern erkannt und umformatiert wird - und die naheliegendste Form, in der das mutmaßlich geschieht, ist die Behandlung als NUMC.

Dann aber sollte man natürlich auch nicht LEAVE TO SCREEN '0'., sondern LEAVE TO SCREEN '0000'. schreiben. Da hast Du dann natürlich recht.

Re: Farbe mit lvc_t_scol definieren

DeathAndPain hat geschrieben: ↑

08.12.2020 12:56

Nur ist Dein Beispielcode oldschool und sollte besser so aussehen😉:

Code: Alles auswählen.

DATA(color) = VALUE LVC_S_COLO( col = '7'
                                int = '0'
                                inv = '0' ).

Kürzer und viel schöner (erfordert mind. Release 7.40).

Und dann vielleicht noch über einen anderen Namen für das Feld nachdenken, da COLOR ein ABAP-Schlüsselwort ist. ABAP erlaubt sowas zwar, aber Schlüsselwörter als Feldnamen zu verwenden, kann tückisch sein. Oder Du verzichtest gleich ganz auf das Feld und übergibst den VALUE direkt als Parameter an die ALV-Methode. Das lokale COLOR-Feld brauchst Du ja nur dafür; anschließend stiftet es ja keinen Nutzen mehr.

Ja hätte ich auch gern so gemacht, leider lässt das unser Release Stand nicht zu :/. Aber den Hinweis mit dem falschen Feldnamen nehme ich gerne mit, danke.