Kopfzeile wird doppelt angezeigt.

Kopfzeile wird doppelt angezeigt.

Hallo,

ich habe ein Problem mit der Ausgabe bei der Kopzeile mit ALV-Grid. Ich habe einen Feldkatalog selbst erstellt für eine Tabelle, die ich mit ALV-Grid ausgeben möchte. Wenn ich dann allerdings die Kopfzeile programmier und mir anzeigen lassen und nun z.B. das Fenster verkleinere und dann wieder vergrößere, verdoppelt sich der Text. Also die Zeile in der Kopfzeile verdoppelt sich jedes Mal, wenn ich das Anzeigefenster verkleinere und dann wieder vergrößere. Echt komisch.... Weiß jemand was das sein könnte und wie das gelöst werden kann?

Die Kopfzeile programmier ich wie folgt:

FORM do_top_of_page.
DATA: ls_line TYPE slis_listheader,
lt_top_of_page TYPE TABLE OF slis_listheader.

* Listenüberschrift: Typ H
CLEAR ls_line.
ls_line-typ = 'H'.
* LS_LINE-KEY: not used for this type
ls_line-info = 'Na'.
APPEND ls_line TO lt_top_of_page.
* Kopfinfo: Typ S
CLEAR ls_line.
ls_line-typ = 'S'.
ls_line-key = 'wie'.
ls_line-info = 'gehts'.
APPEND ls_line TO lt_top_of_page.
* Aktionsinfo: Typ A
CLEAR ls_line.
ls_line-typ = 'A'.
* LS_LINE-KEY: not used for this type
ls_line-info = 'so?'.
APPEND ls_line TO lt_top_of_page.

CALL FUNCTION 'REUSE_ALV_COMMENTARY_WRITE'
EXPORTING
it_list_commentary = lt_top_of_page.

ENDFORM.

Vielen Dank im Voraus.

Grüße

Re: Kopfzeile wird doppelt angezeigt.

Hi,

vielen Dank schon mal

Ich bin noch ziemlicher Anfänger.

Könntest du mir vielleicht ein Beispiel geben, wie ich das am besten mache?

Vielen Dank im Voraus.

Re: Kopfzeile wird doppelt angezeigt.

a-dead-trousers hat geschrieben:Am Beginn deiner Form-Routine:

Code: Alles auswählen.

IF gd_top_of_page EQ abap_true.
  RETURN.
ENDIF.

Oder kürzer:

Re: Kopfzeile wird doppelt angezeigt.

Ich halte das für Ansichtssache und bin ein ganz großer Fan des CHECK-Befehls, der nach meiner Überzeugung den Code in den allermeisten Fällen besser lesbar macht. Er ist ja von der SAP auch nicht als deprecated eingestuft. Natürlich muss man wissen, was er bedeutet. Aber wer die ABAP-Befehle nicht kennt, kann nicht ABAP programmieren. Jedenfalls gilt das für grundlegende Befehle, zu denen ich den CHECK allemal rechne.

Wenn ich mir überlege, was durch OO von ABAP-Programmierern für ein geistiges Abstraktionsvermögen gefordert wird, dann finde ich es geradezu lächerlich, sich darüber zu beklagen, dass man bei CHECK und EXIT hinschauen muss, ob man sich in einer Schleife befindet oder nicht.

Ich würde den CHECK vielleicht nicht unbedingt in unklaren Kontexten verwenden. Innerhalb von LOOP-Schleifen überschaubarer Länge halte ich ihn aber ebenso für in Ordnung wie in Unterprogrammen, die entweder so klein sind, dass man sie mühelos überblicken kann, oder bei denen der CHECK so nahe am Anfang der Routine steht, dass beim Lesen keine Zweifel über seine Wirkung entstehen können. Dieser Thread hier kann hier als Paradebeispiel dienen: Wenn der CHECK der erste Befehl einer FORM-Routine ist, dann besteht nicht die mindeste Unklarheit darüber, was er bewirkt. Da ist ein sperriges IF-ENDIF-Konstrukt allemal unübersichtlicher zu lesen.

Ist die FORM-Routine länger und enthält vielleicht auch noch ausgedehnte Schleifen, dann wäre ich mit CHECK und seinem Schwesterbefehl EXIT auch vorsichtig, weil sich dann nicht auf den ersten Blick erschließt, ob man sich in einer Schleife befindet oder nicht (und nur davon hängt seine Wirkung ja ab). Aber selbst dann kann man ihn nutzen, wenn er dicht am Anfang der Schleife steht, so dass man den LOOP/WHILE/whatever-Befehl und den CHECK gleichzeitig im Blick hat. Ich ergänze CHECKs und EXITs auch gerne um eine Kommentarbemerkung, die die Funktion an der jeweiligen Stelle verdeutlicht. Beim EXIT reicht dafür ein Bezug auf den betreffenden Block, z.B.
Dann ist das perfekt lesbar und verständlich.

Wir haben *einige* uralte, rießige (+10.000 Zeilen) Programme im Einsatz

Viele Zeilen zu haben ist erst mal kein Drama, solange sich die Programmierer an die klassischen Grundsätze strukturierter Programmierung gehalten haben. Die besagen, dass man eben keinen schlauchförmigen Spaghetticode schreiben soll, sondern seinen Quellcode möglichst fein in aussagekräftig benamte Unterprogramme gliedern soll. Wenn die einzelne Formroutine eine klar definierte Schnittstelle, optimalerweise sogar noch eine kurze Funktionsbeschreibung im Kopfkommentar hat (ich weiß, das machen die wenigsten) und ihre Länge nicht aus dem Ruder läuft, dann mag der Gesamtcode gerne 30.000 Zeilen haben. Den kann man dann vielleicht auf ein paar Includes aufteilen, damit der Scrollbalken länger und weniger empfindlich wird, aber das Programm bleibt dann gut wartbar. Sind einzelne Formroutinen zu lang, dann ist das ein Zeichen dafür, dass sich ihr Schöpfer vor einer Untergliederung in Teil-Unterprogramme gedrückt hat, die dann angezeigt gewesen wäre.

Die Schuld für Schlamperei in diesen Bereichen dem CHECK-Befehl zuzuschieben finde ich aber in höchstem Maße unfair. Wenn bei eurem Altcode die Programmierer den Code sequenziell runtergeschrieben haben und in ihren wenigen Form-Routinen üppig globale Variablen benutzen, so dass man nicht weiß, was reingeht, was rausgeht und woher das darin Befindliche seinen Wert hat, am besten noch unter Nutzung des guten ABAP Memory, dann ist das in der Tat schlecht verständlich, hat aber mit dem CHECK nichts zu tun.

Re: Kopfzeile wird doppelt angezeigt.

Wie du richtig sagst, gibt es durchaus Anwendungsbeispiele in denen der Befehl sogar Sinn macht. Zum Beispiel in LOOPs wo man nach der ersten Fundstelle nicht mehr weiterzusuchen braucht oder eben in kleinen(!) Methoden bei denen die Weiterverarbeitung bei einem fehlerhaften Parameter nicht mehr sinnvoll ist

Und den Fall haben wir doch hier. Wenn der erste Befehl der Form (oder Methode) ein CHECK ist, dann ist es doch einerlei, wieviel Code dahinter noch kommt; dann ist das auf jeden Fall völlig problemlos verständlich, was da passiert.

In meinen Augen wirfst Du im übrigen Sachen durcheinander, die nicht zusammengehören: Im Gegensatz zu CHECK und EXIT gehört der CONTINUE-Befehl nicht zu den Befehlen, deren Nutzung die SAP nur eingeschränkt empfiehlt. Die Bedeutung von CONTINUE ist auch ebensowenig kontextabhängig wie die von ENDLOOP. Wenn Schleifen unübersichtlich lang werden, dann muss man ihren Inhalt in Unterprogramme gliedern. Das nicht zu tun ist der Fehler, nicht CHECK oder CONTINUE! Sich stattdessen auf diese Befehle zu kaprizieren halte ich für einen Denkfehler.

Wenn Du den Inhalt Deiner 300 Zeilen-Schleife ordentlich modularisiert hast, dann steht da an Ende noch:
Und da kann mir keiner sagen, dass das nicht gut lesbar und verständlich wäre.

Davon abgesehen hast Du hier ja postuliert, statt CHECK ein IF-ENDIF-Konstrukt zu verwenden. Im Sinne Deiner eigenen Argumentation kommst Du damit aber vom Regen in die Traufe, denn in der Schleife wird aus CHECK dann IF-CONTINUE-ENDIF, was länger, aber nicht besser ist (auch wenn der CONTINUE deutlich macht, dass wir uns in einer Schleife befinden). Oder in diesem Fall hier IF-RETURN-ENDIF. Den RETURN-Befehl mag ich zwar auch, aber letztlich ist er das CHECK- oder EXIT-Gegenstück zum CONTINUE-Befehl, nur für den anderen Fall (nämlich dass man sich nicht in einer Schleife befindet). (Na gut, ein kleines bisschen mehr ist er schon, da man sich damit auch direkt aus einer Schleife verabschieden kann.)

Re: Kopfzeile wird doppelt angezeigt.

Die EXITs verwende ich notgedrungen nur um performant Schleifen zu verlassen, solange es kein READ TABLE mit CP (Contains Pattern) gibt.

Wenn das der einzige Fall ist, dann würde ich gerne mal eine DO-Schleife ohne TIMES-Angabe von Dir sehen. EXIT und RETURN sind da die einzigen Möglichkeiten zu verhindern, dass man in einer Endlosschleife endet. (wenn man mal von radikalen Lösungen wie LEAVE TO SCREEN '0' oder MESSAGE TYPE 'A' absieht) Aber auch bei WHILE verwende ich EXIT gerne mal, wenn ich einen Absprung jenseits der regulären WHILE-Bedingung brauche.

Ich bin aber auch der Meinung, dass ein READ TABLE (alternativ die entsprechende 7.40-Syntax) mit anderen Bedingungen als nur Gleichheit das größte Loch ist, das ABAP derzeit zu bieten hat. Schade, dass sie das im Rahmen von 7.40 nicht geschlossen, sondern im Gegenteil dieselbe Beschränkung auch wieder in die neue Syntax eingebaut haben. Es hätte sich doch gut gelesen, wenn man hätte schreiben können:

ergebnis = meinetabelle[ spalte_a > 1 ].

Klar kriegt man damit ggf. nur die erste Fundstelle, aber a) ist das bei Prüfung auf Gleichheit auch nicht anders und b) ist das häufig gut genug, oder man weiß sogar aufgrund von Konsistenzkriterien, dass es mehrere Fundstellen gar nicht geben kann. Dass man dafür immer eine sperrige LOOP-Schleife aufmachen muss, in der ggf. nicht mehr als ein EXIT-Kommando drinsteht, nervt.

Ein Vorteil eines IF-ENDIF gegenüber einem CHECK oder CONTINUE im Sinne der Lesbarkeit ist mit gerade eingefallen. Bei einem Doppelklick im Editor auf das IF lande ich beim ENDIF. Mit ALT+Doppelklick sogar bei eventuell vorhandenen ELSE[IF]s. Und außerdem lassen sich diese Blöcke mit Code-Folding wegblenden.

Damit löst Du aber nur ein Problem, dass Du beim CHECK gar nicht erst hast. Ein IF-RETURN-ENDIF-Block ist sperrige drei Zeilen lang, die man damit auf eine Zeile verdichten kann. EIn CHECK hat von Hause aus nur eine Zeile, und da steht die volle Information drin, ohne dass man es nötig hätte, der Übersichtlichkeit halber was wegzublenden.

Bei einem CHECK oder CONTINUE muss man da oft mehr Hirnschmalz reinstecken um zu erkennen wie sich dieser Befehl auf den Gesamtlauf auswirkt.

Das nehme ich anders wahr als Du. Wenn ich in einem LOOP einen Fall feststelle, bei dem ich die aktuelle Tabellenzeile nicht weiter bearbeiten muss, dann finde ich ein CONTINUE für den Leser bedeutend plakativer, als wenn ich den ganzen Rest des LOOPs in einen IF-ENDIF-Block verpacke und der Leser sich erst durch probehalbes Einklappen davon überzeugen muss, dass nach dem IF die Schleife endet und da nichts mehr passiert. Und wenn Du dann noch mehrere davon hast, dann erzeugt jeder davon eine weitere Einrückung, so dass man in der selbst heute noch schmalspurigen SE38 oder gar im Debugger kaum noch was sieht, weil der halbe Code rechts vom sichtbaren Fenster steht. Hohe Einrückungstiefen wirken schon optisch abschreckend auf den Leser, da sie eine hohe Komplexität suggerieren, die in diesem Fall aber gar nicht vorhanden ist. Es gibt nur halt innerhalb der Schleife einige Bedingungen, bei denen für diese Tabellenzeile die Schleife nicht weiter abgearbeitet werden muss.

So unterscheiden sich die Geschmäcker.

Re: Kopfzeile wird doppelt angezeigt.

ralf.wenzel hat geschrieben:Es ist in jedem Falle ganz übel, eine Anweisung zu definieren, die kontextabhängig unterschiedliches Verhalten aufweist.

Könntest du dann bitte auch mal gegen den MODIFY-Befehl wettern und ebenso gegen das "+" und vor allem das "-" oder "=" Zeichen aus dem selben Grund?

a-dead-trousers hat geschrieben:Ich mag die CHECKs und CONTINUEs einfach nicht, weil sie mir schon viel zu oft Hirnkrämpfe verursacht haben.

Jeder hat da wohl so seine eigenen Vorlieben und Vorstellungen. Ich verwende die liebend gerne, weil m.E. die Lesbarkeit stark zunimmt ( so wie ich es zumindest verwende ).

a-dead-trousers hat geschrieben:Die EXITs verwende ich notgedrungen nur um performant Schleifen zu verlassen, solange es kein READ TABLE mit CP (Contains Pattern) gibt.

Warum "notgedrungen"? Ist nicht gerade der Sinn des "EXIT"-Befehls einen Verarbeitungsblock ( Schleife ) zu verlassen? Und wenn du "EXIT" nicht magst - du könntest auch immer einen Try-Catchblock verwenden um durch eine Exception die Schleife zu verlassen.

a-dead-trousers hat geschrieben:Die RETURNs verwende ich nur bei Parameterprüfungen um schnell eine Methode zu verlassen und mir die Einrückungen zu sparen.

Spätestens wenn in der Methode geschachtelte Schleifen sind und du in der innersten der Schleifen merkst, dass du gar nicht weitermachen willst/brauchst. Die üblichen Alternativen arbeiten mit Hilfsvariablen, die versuchen die Funktionalität des RETURNs zu erreichen und erschweren die Wart/Lesbarkeit durch die Verwendung kaskadierender EXITs.

Re: Kopfzeile wird doppelt angezeigt.

ralf.wenzel hat geschrieben: Wenn ich aber schreibe "Zuweisungen macht man mit =, Vergleiche mit EQ", wie ich das hier schon gemacht habe, bist du der erste, der hinter seinem Stein hervorkriecht und meckert.

*Nickt* --> aber ich wettere auch nicht so sehr gegen überladene Befehle