In diesem Kapitel widmen wir uns der Programmierung von Selektionsbildschirmen. Sie lernen z. B., wie Sie Eingabefelder positionieren, Eingabemöglichkeiten einschränken und das Layout des Bildschirms gestalten.
11 Selektionsbildschirme 

Bislang haben wir die Startwerte für Felder hart codiert. In diesem Kapitel lernen Sie, dem ABAP-Report durch einige Anweisungen beim Programmstart mitzuteilen, mit welchen Werten er arbeiten soll, ob z. B. eine Liste erzeugt werden soll oder nicht, wie oft Schleifen durchlaufen werden und welche Daten aus der Datenbank selektiert werden sollen.
In der klassischen SAP-GUI-Umgebung existieren drei Arten von Dialogbildschirmen:
-
klassische Dynpros, die Ihnen aus den typischen Anwendungstransaktionen bekannt sein dürften
-
Selektionsbilder, die in der Regel vor der Ausführung eines Reports für die Parametereingabe dargestellt werden
-
Listausgaben, die normalerweise am Ende der Verarbeitung eines Reports ausgegeben werden
Die Erstellung klassischer Dynpros ist eine hohe Kunst und erfordert die Beherrschung eines speziellen grafischen Editors, des grafischen Screen Painters, sowie einer besonderen Variante der ABAP-Sprache, die eigens für die Programmierung von Dynpro-Ablauflogik geschaffen wurde. Damit befassen wir uns aber nicht näher, da sie ebenso wie die browserbasierten Programmiertechniken eher etwas für fortgeschrittene ABAP-Entwickler sind. Die Erzeugung von Listausgaben ist hingegen einfach, und Sie werden in diesem Kapitel einiges darüber lernen.
Das Selektionsbild schließlich ist das Hauptthema dieses Kapitels. Es dient dazu, einen Report vor der eigentlichen Programmausführung über einen Benutzerdialog mit Startwerten versorgen zu können. Bisher mussten Sie den Variablen im Quellcode Werte zuweisen; im Selektionsbild können Sie diese Werte über einen Dialog eingeben.
[»] Listausgabe am Bildschirm
Wenn Sie das Selektionsbild ausgefüllt und abgeschickt haben, läuft der Report allerdings wie bisher komplett durch und produziert am Ende ein Ergebnis, z. B. eine Listausgabe. Während der Laufzeit des Reports können Sie daher nicht mehr steuernd eingreifen. Die Listausgabe erfolgt standardmäßig nicht mehr – wie früher – auf Papier, sondern in einer Bildschirmliste. Diese Ausgabe produziert ein eigenes Dialogprogramm: den Listprozessor.
Möchten Sie die Bildschirmliste gedruckt auf Papier sehen, müssen Sie den Druck von der Bildschirmliste aus über System • Liste • Drucken veranlassen oder den Druck im ABAP-Quellcode durch besondere Anweisungen sofort auf den Drucker umleiten, beispielsweise durch die Anweisung NEW-PAGE PRINT ON. Auf die Besonderheiten der »Papierproduktion« soll hier aber nicht weiter eingegangen werden.
Das Besondere an Listausgaben und Selektionsbildern ist, dass sie nicht mit dem grafischen Screen Painter als klassisches Dynpro (dynamisches Programm) vom Entwickler gezeichnet und geschrieben, sondern ausschließlich implizit über ABAP-Anweisungen generiert werden, der Listbildschirm beispielsweise mit der WRITE-Anweisung. Das macht ihre Erzeugung besonders einfach und programmierfreundlich. Für den Einstieg in ABAP hat dies den Vorteil, dass die Dynpro-Ablauflogik, die bei klassischen Dynpros manuell programmiert werden muss, hier vom System unsichtbar im Hintergrund erzeugt und verarbeitet wird.
Alle Dynpros – ob Selektionsbilder oder klassische Dynpros – sind Komponenten von Programmen. Es gibt verschiedene Programmtypen; die Programmtypen, die Dynpros enthalten können, lauten ausführbares Programm, Funktionsgruppe und Modulpool. Modulpools sind weitgehend veraltet und begegnen Ihnen nur noch in älteren Anwendungen. Selektionsbilder sind meist in ausführbaren Programmen (auch Report genannt) enthalten und klassische Dynpros aus Gründen der besseren Modularisierung in Funktionsgruppen. Diese fortgeschrittenen Techniken zu beleuchten, würde aber den Rahmen dieses Buches überschreiten. Wir beschäftigen uns in diesem Kapitel mit dem Selektionsbild, das erscheint, bevor ein ABAP-Report beginnt.
Bei Reports wird das vom System als Standardselektionsbild generierte Dynpro automatisch bei der Programmausführung durch die Laufzeitumgebung aufgerufen und gesteuert; es hat immer die Dynpro-Nummer 1.000. Für den Anwender ist es allerdings nur sichtbar, wenn im Report über ABAP-Anweisungen Eingabeparameter vorgesehen sind. Nur durch diese ABAP-Anweisungen wird das Dynpro für das Selektionsbild im Hintergrund generiert und mit den Eingabeparametern sichtbar.
Aus diesem Grund müssen wir an dieser Stelle nicht übermäßig tief in die Welt der Dialogprogrammierung einsteigen. Sie sollten allerdings dennoch einige grundsätzliche Zusammenhänge kennenlernen. Dieses Wissen ist sowohl nötig, um die Selektionsbildverarbeitung zu verstehen als auch, um sich die Ereignisse im Zusammenhang mit den Selektionsbildern zu erschließen.
11.1 Ereignisse 

Ereignisse bezeichnen Verarbeitungsblöcke. Die Struktur eines Ereignisses beginnt mit dem Ereignisschlüsselwort; das Strukturende ist nur implizit vorhanden. Ein Ereignis endet beispielsweise, wenn ein neues Ereignis beginnt, ein Unterprogramm beginnt oder der Report endet. Wenn Sie im Quellcode des Reports mit der Programmsteuerung über Ereignisse einmal begonnen haben, müssen Sie diesen Stil deshalb beibehalten; anderenfalls würden alle ABAP-Anweisungen zum zuletzt angesprungenen Ereignis zählen und dort ausgeführt.
[+] Ereignisse im Quellcode
In der Struktur des Ereignisses stehen die zugehörigen ABAP-Anweisungen. Ereignisse werden in einer von der Laufzeitumgebung festgelegten Folge im Quellcode des Reports gesucht und verarbeitet. Deshalb ist es technisch gesehen gleichgültig, in welcher Reihenfolge die Ereignisse im Report vorkommen; praktisch sind Reports aber viel besser lesbar, wenn die Ereignisse im Report in logischer Reihenfolge angeordnet werden.
11.1.1 Reihenfolge von Ereignissen 

Der Ablauf für den Programmstart und die Programmausführung ist in der Laufzeitumgebung fest vorgegeben. Wenn Sie einen Report starten, stellt sich der Ablauf nach dem Laden des Programms vereinfacht folgendermaßen dar:
-
LOAD-OF-PROGRAM
Unmittelbar nach dem Laden des Programms wird der Verarbeitungsblock LOAD-OF-PROGRAM ausgeführt, sofern er im Report als Ereignis definiert ist. -
INITIALIZATION
Danach wird das Ereignis INITIALIZATION im Report gesucht und ausgeführt. Beispielsweise stehen bei diesem Ereignis Anweisungen, die Werte für das Selektionsbild ermitteln oder dieses modifizieren. Allerdings wird das Ereignis nur einmal – beim ersten Programmstart – durchlaufen.Als Nächstes prüft die Laufzeitumgebung, ob im Report ein Selektionsbild deklariert ist. Dies ist der Fall, wenn Sie mit ABAP-Anweisungen mindestens ein Eingabefeld deklarieren. Dann geht die Kontrolle an den Selektionsbildprozessor über, einen speziellen Dynpro-Prozessor. Bevor der Selektionsbildprozessor das Bild an den Benutzer sendet, übernimmt er die Feldwerte, die im Ereignis INITIALIZATION ermittelt wurden, und stellt sie in die Eingabefelder. Auch andere Ereignisse kann der Selektionsbildprozessor auslösen, bevor der Anwender das Selektionsbild sieht.
-
AT SELECTION-SCREEN
Nachdem der Anwender den Bildschirm gesehen, ausgefüllt und abgeschickt hat, löst der Selektionsbildprozessor das Ereignis AT SELECTION-SCREEN aus.Von diesem Ereignis gibt es eine Grundform und mehrere Varianten, und es ist der richtige Zeitpunkt, um aufwendigere Eingabeprüfungen vorzunehmen. Finden Sie bei der Prüfung einen Fehler, können Sie verhindern, dass der Report mit den »falschen« Daten zu arbeiten beginnt. Stattdessen können Sie das Selektionsbild mit entsprechender Fehlermeldung wieder anzeigen lassen und eine »richtige« Eingabe erzwingen.
-
START-OF-SELECTION
Anschließend geht die Kontrolle wieder an den ABAP-Prozessor über, und das Ereignis START-OF-SELECTION wird im Report gesucht und prozessiert.
Falls keine weiteren Ereignisse mehr im Quellcode eingebaut wurden, wird am Ende des Reports zur Listausgabe die Kontrolle an den Listprozessor übergeben. Auch der Listprozessor selbst kann wiederum bestimmte Ereignisse im Quellcode suchen und ausführen.
11.1.2 Beispiele für Ereignisse 

Kommen wir wieder zur praktischen Anwendung: Wenn Sie in unserer Teilnehmertabelle einen neuen Teilnehmer erfassen möchten, wäre es beispielsweise praktisch, wenn Sie nicht immer manuell nachsehen müssten, welche die nächste freie Teilnehmernummer ist.
Genau dies ist eine Aufgabe, die das Ereignis INITIALIZATION für Sie übernehmen kann, indem es die nächste freie Nummer vorschlägt. Dieses Ereignis wird prozessiert, bevor das Selektionsbild gezeigt wird. Schauen Sie sich folgendes Codebeispiel an:
INITIALIZATION.
SELECT * FROM zteilnehmer02 INTO wa_zteilnehmer02
ORDER BY PRIMARY KEY.
tnr = wa_zteilnehmer02-tnummer.
ENDSELECT.
tnr = tnr + 1.
neutnr = tnr.
Zunächst wird einfach die Teilnehmertabelle gelesen (sicherheitshalber sortiert nach dem Tabellenschlüssel); im Feld TNR wird die Nummer mitgezählt. Die letzte Zeile hat die höchste Nummer, d. h. die nächsthöhere Nummer ist für einen neuen Teilnehmer frei. Diese Nummer soll im Selektionsbild als Vorschlag im Eingabefeld erscheinen und wird deshalb in den Parameter NEUTNR übertragen.
Dieses Ereignis wird von der Laufzeitumgebung prozessiert, bevor das Selektionsbild angezeigt wird. Wie beschrieben, beginnt es mit dem Ereignisschlüsselwort INITIALIZATION und endet implizit. Soll der Report nach dem Selektionsbild noch Anweisungen ausführen, muss in der Folgezeile ein anderes Ereignisschlüsselwort stehen.
Beispielsweise könnte das Ereignis AT SELECTION-SCREEN die vorgenommenen Eingaben im Selektionsbild prüfen. Die Eingabeprüfung kann sich dabei auf alle Felder des Selektionsbildes beziehen oder gezielt auf einzelne Felder.
Angenommen, Sie möchten sicherstellen, dass die verwendete neue Teilnehmernummer größer oder gleich der vorgeschlagenen neuen Teilnehmernummer ist, dann könnten Sie die Eingabe einer »falschen« Teilnehmernummer verhindern. Hierzu schreiben Sie eine spezielle Eingabeprüfung für das Feld NEUTNR, das für die neue Teilnehmernummer vorgesehen ist:
AT SELECTION-SCREEN ON neutnr.
* Eingabeprüfung für neue Teilnehmernummer
IF neutnr < tnr.
* Anweisungsblock für Fehlerbehandlung
ENDIF.
Falls ein Benutzer versucht, eine bestehende Teilnehmernummer für einen neuen Teilnehmer einzupflegen, wird das Selektionsbild so lange immer wieder mit einer Meldung in der Statuszeile angezeigt, bis eine zulässige Teilnehmernummer eingegeben wird. Wie diese Fehlerbehandlung genau funktioniert, erfahren Sie in Abschnitt 11.6, »Ergänzende Textobjekte«. Dieses und ein weiteres Beispiel für den rückwärtslaufenden Sekundenzähler finden Sie auch im Quellcode Z_TEILNEHMERLISTE11_B (siehe Abschnitt 11.8, »Codebeispiel zum Selektionsbild (einfache Form)«).
Im Beispiel bezieht sich das Ereignis AT SELECTION-SCREEN nur auf das Eingabefeld NEUTNR. Nachdem der Anwender im Selektionsbild auf den Ausführen-Button () geklickt hat, wird es vom Selektionsbildprozessor aufgerufen. Ist der Eingabewert kleiner als die vorgeschlagene Teilnehmernummer, wird der Anweisungsblock für die Fehlerbehandlung ausgeführt. Häufig besteht dieser Anweisungsblock aus einer Nachricht in der Statuszeile mit Hinweisen für die Neueingabe. Wie Sie diese Nachrichten verwalten und senden, wird ebenfalls in Abschnitt 11.6, »Ergänzende Textobjekte«, geschildert.
[»] Implizites Ende nicht vergessen!
Ist die Bedingung nicht erfüllt, wird mit der Anweisung nach ENDIF fortgefahren. Auch hier darf man das implizite Ende eines Ereignisses nicht vergessen: Soll der Report die eingegebenen Daten anschließend verarbeiten, ist in der Folgezeile das Ereignisschlüsselwort START-OF-SELECTION oder ein entsprechendes Ereignisschlüsselwort notwendig.