[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]

Vorbemerkung

Der viel geschmähte Reportdesigner von Visual FoxPro hat sicherlich seine Ecken und Kanten, aber mit ein paar Tricks und Kniffen offenbart er ein überraschendes Leistungspotential.

Die nachfolgende Zusammenstellung soll Ideen und Ansatzpunkte liefern, sich diesem Tool mit etwas größerer Aufmerksamkeit zu nähern, um sich die vielfältigen Möglichkeiten nutzbar zu machen. Im Rahmen dieser Session kann allerdings nicht auf jeden Aspekt mit der höchstmöglichen Tiefe eingegangen werden, deshalb sollen die Ausführungen als Anregung dienen, sich mit dem VFP-Reportdesigner etwas intensiver zu beschäftigen.

Da die Übersetzungen von VFP-Fachtermini oft zu sehr unglücklichen Begriffen geführt haben, werden in diesem Text ausschließlich die englischen VFP-Termini verwendet. Eine Übersetzungsliste der wichtigsten der kursiv dargestellten Termini ist am Ende beigefügt.

Grundprinzipien

Klassifizierung von Druckausgaben

Druckausgaben in einem Datenbanksystem lassen sich aus Sicht der Komplexität des je Datensatz auszudruckenden Detailbereichs (Detail Band) in zwei Kategorien einteilen:

• Listen
• Formulare

Listen sind relativ einfach strukturiert und haben einen sich meist massenhaft wiederholenden Detailbereich. Typische Beispiele für derartige Ausdrucke sind Preislisten, Adresslisten usw.

Für die Erstellung von Listen kann der Reportdesigner von VFP relativ problemlos eingesetzt werden.

Formulare dagegen haben einen komplexeren Detailbereich, der von mehreren Zeilen bis hin zu ganzen Seiten groß sein kann. Solche Detailbereiche sind oft aufwendig strukturiert und haben meist auch eine anspruchsvollere grafische Gestaltung (z.B. das Antragsformular für eine Versicherung).

Bei dem Erstellen von Formularen mit dem VFP-Reportdesigner sind einige Einschränkungen zu beachten:

• Die Anzahl und Komplexität der eingesetzten grafischen Elemente (Linien, Rahmen usw.) erfordert einen großen Zeitaufwand bei der Erstellung und bringt die Print-Engine von Visual FoxPro auch schon mal an die Grenze ihrer Leistungsfähigkeit.

• Detailbereiche über mehrere Seiten hinweg sind normalerweise nicht möglich (aber da gibt es Abhilfe).

Spannend wird die Angelegenheit, wenn man listen- und formularartige Darstellungen kombinieren will. Hier hängt die Realisierbarkeit von der relativen Lage der einzelnen Bereiche zueinander ab:

• Sind diese verschiedenartigen Bereiche vertikal zueinander angeordnet (also übereinander), dann ist eine Erstellung solcher Reports mit dem VFP-Reportdesigner prinzipiell möglich:
  

• Nur sehr wenig Spielraum gib es in VFP für Reports, bei denen listen- und formularartige Darstellungen horizontal (also nebeneinander) angeordnet werden sollen (z.B. eine Rechnung mit rechts daneben positioniertem Überweisungsträger):

Die Erstellung der in VFP möglichen kombinierten Reports wird weiter unten detaillierter besprochen.

Bedienung des Reportdesigners

Die Bedienung des Reportdesigners ist etwas gewöhnungsbedürftig:

• Die relevanten Menüpunkte sind über vier Menüpads des VFP-Menüs verteilt:

• Am verstecktesten liegt der Menüpunkt "Page Setup" im Menü "File". Hier kann man man z.B. die Papier-Ausrichtung, die Spaltenanzahl sowie diverse weitere Einstellungen vornehmen.

• Arbeitet man mit dem Reportdesigner, dann tauchen auch im Menü "View" einige spezielle Menüpunkte auf: "Design", "Preview", "DataEnvironment..." sowie diverse weitere Einträge.

• Im Gegensatz zum sonstigen Inhalt des Menüs "Format" befinden sich hier völlig reportdesigner-spezifische Menüpunkte zur Anordnung und Formatierung von Report-Elementen.

• Das Menü "Report" enthält ausschließlich reportdesigner-spezifische Punkte.

• Auf der Arbeitsfläche des Reportdesigners kann man bestimmte Bereiche mit einem RightClick anwählen und bekommt dann ein Kontextmenü.

• Bei anderen Bereichen hat der DoubleClick die Bedeutung, eine Spezifikationsmaske zu öffnen.

• Bei einigen Bereichen, z.B. direkt auf den Trennstreifen zwischen den Bands sind sowohl RightClick als auch DoubleClick zugelassen, wobei sie zu unterschiedlichen Ergebnissen führen!

• Datenfelder können per Drag&Drop aus dem DataEnvironment oder aus dem Databasedesigner auf die Arbeitsfläche des Reports gezogen werden.

Die Höhe der verschiedenen Report Bands kann man durch vertikales Verschieben des zugehörigen Separator Bars erreichen.

Speicherung von Reportdefinitionen

Definitionen von Reports werden in Visual FoxPro in Datei-Paaren mit der Endung .FRX/.FRT gespeichert. Technisch gesehen verbirgt sich dahinter eine DBF-Tabelle mit einer Memodatei - und diese Tabelle kann ganz normal mit USE geöffnet und mit BROWSE angezeigt werden.

Eine minimale Dokumentation der Interna dieser Datei findet man in dem Verzeichnis FILESPEC innerhalb des Installationsverzeichnisses von Visual FoxPro. Weiterführende Informationen sind z.B. dem Artikel "Demystifying Visual FoxPro Report Files" von John S. Koziol aus dem FoxTalk von August 2000 zu entnehmen.

Abarbeiten von Reports

Das Abarbeiten von Reports erfolgt über den "REPORT FORM"-Befehl:

REPORT FORM FileName1 | ? 

[ENVIRONMENT] 
[Scope] [FOR lExpression1] [WHILE lExpression2] 
[HEADING cHeadingText] 
[NOCONSOLE] 
[NOOPTIMIZE] 
[PLAIN] [RANGE nStartPage [, nEndPage]] 
[Preview [[IN] WINDOW WindowName | IN SCREEN] 
[NOWAIT]] 
[TO PRINTER [PROMPT] | TO FILE FileName2 [ASCII]] 
[NAME ObjectName] 
[SUMMARY]

Einige dieser Optionen bergen ungeahnte Möglichkeiten in sich, wie weiter unten erläutert wird. Deshalb lohnt es sich in jedem Fall, alle Möglichkeiten des REPORT-Befehls genauestens zu studieren.

Überblick über die Hauptbestandteile einer Report-Definition

Die Hauptbestandteile einer Report-Definition sind:

• das DataEnvironment
• die Arbeitsfläche mit den Report Bands
• Gruppierungen, Berichtsvariablen und Expressions

Im DataEnvironment kann man die am Report beteiligten Datenquellen festlegen (muß man aber nicht, ein Report kann auch auf Daten zugreifen, die im Vorfeld durch die vorgelagerte Programmlogik bereitgestellt wurden).

Auf der Arbeitsfläche werden die Ausgabefelder sowie optische Elemente wie Linien und Rahmen gestaltet und den einzelnen Report Bands zugeordnet.

Gruppierungen, Berichtsvariablen und Expressions sind Mittel zur report-internen Datenaufbereitung, können aber auch für weitreichende effektvolle Tricks eingesetzt werden (siehe weiter unten).

Expressions / Events

Besondere Beachtung verdienen die Stellen der Report-Definition, wo man sogenannte Expressions einsetzen kann. Mit Expression ist ein nach FoxPro-Konventionen gültiger Berechnungsausdruck gemeint, der eine fast beliebige Komplexität haben kann.

Im einfachsten Fall besteht eine solche Expression aus einem einzelnen Feldnamen aus der Tabelle, über die der Report erstellt wird, z.B. Customer.PostalCode.

Eben so gut können aber auch Verknüpfungen von Feldern (Customer.PostalCode + " " + Customer.City) gebildet oder VFP-Funktionen einbezogen werden ( ALLTRIM(Customer.PostalCode) ).

Natürlich ist auch der Zugriff auf Speichervariablen oder Eigenschaften von Objekten möglich, wenn gesichert ist, daß diese zum Zeitpunkt der Abarbeitung des Reports zur Verfügung stehen.

Bei all diesen Varianten muß lediglich beachtet werden, daß das Ergebnis der Expression vom Datentyp her paßfähig zum Verwendungszweck ist.

An diese Stelle sei darauf hingewiesen, daß in Expressions natürlich auch Aufrufe von User Defined Functions (UDF) möglich sind. Daraus ergeben sich zwei sehr weitreichende Möglichkeiten:

In einer solchen UDF kann man beliebig komplexe Berechnungsalgorithmen unterbringen, die in einer einzelnen Expression ggf. nicht abzubilden sind.

UDFs innerhalb von Expressions werden quasi als Event bei jedem Auswerten der Expression gefeuert und können damit Aufgaben übernehmen, die von dem eigentlichen Zweck der Expression u.U. sehr weit entfernt sind. Allerdings muß man in diesem Zusammenhang folgendes beachten:

• Die Auswertung der Expressions und damit der Aufruf der jeweiligen UDF erfolgt durch die Report-Engine von Visual FoxPro nach z.T. schwer zu durchschauenden Prinzipien, u.U. sogar mehrfach.

• Dies ist solange relativ unkritisch, wie man UDFs zur Speicherung etwas komplexerer Berechnungsalgorithmen verwendet.

• Werden in einer UDF allerdings kumulative Berechnungen ausgeführt (x=x+1) oder sogar völlig REPORT-fremde Aktivitäten ausgelöst, dann ist es u.U. unerwünscht, daß die Abarbeitung je Report-Item unbeeinflußbar mehrfach abläuft.

Die ungewollte Mehrfachabarbeitung von UDFs kann man verhindern, indem man als zusätzlichen Parameter eine Kennung mitgibt, anhand derer die UDF erkennen kann, ob dies ein erstmaliger oder ein ungewollt zusätzlicher Aufruf ist.

Ruft man z.B. aus dem Seitenfuß eine UDF auf, die eine Seitensumme auf eine andere Variable kumulieren soll, dann kann man diese UDF mit der zusätzliche Übergabe der Seitennummer absichern:

LPARAMETER tnPageSum, tnPageNo 
IF NOT ( m.pnPageNo == m.tnPageNo ) 
   pnPageSumAll = m.pnPageSumAll + m.tnPageSum 
   pnPageNo = m.tnPageNo 
ENDIF
...

Die bei solchen Konstrukten verwendeten Variablen müssen vor dem Starten des Berichtes als PRIVATE-Variablen definiert und ggf. initialisiert werden. Noch besser eignen sich allerdings Properties eines zu diesem Zweck vor der Berichtsabarbeitung instanzierten Objektes.

Trotzdem kann es beim Einsatz von UDFs zu Problemen kommen, wenn mit der Seitenansicht gearbeitet wird, da dort die freie Vor- und insbesondere die Rückwärtsnavigation zu unerwarteten Effekten führen kann.

Im einfachsten Fall kann man diesem Problem dadurch begegnen, wenn man die Anzeige der problematischen Controls davon abhängig macht, ob der Bericht im Modus Seitenansicht angezeigt wird.

Dies erreicht man durch eine Abprüfung von WEXIST("Printing...") in der englischen bzw. von WEXIST("Drucken...") in der deutschen Version. Wenn diese Expression .T. liefert, dann ist das kleine Fensterchen mit der Nummer der gerade gedruckten Seite sichtbar, welches nur beim wirklichen Ausdrucken angezeigt wird!

Hauptaspekte eines VFP-Reports

Das DataEnvironment von Reports

Das ist der Teil der Report-Definition, in dem man die Bezüge zu den im Report zu verwendenden Datenquellen hinterlegen kann (ähnlich der Datenumgebung einer VFP-Maske).

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]