Session D-REP

Der Report Designer
und GenRepoX

Markus Egger
EPS-Software/ MTI-Software/ ProLib Software

Der Visual FoxPro - Report Designer

Der Report Designer ist eines der wichtigsten und zugleich eines der am stärksten vernachlässigten Tools von Visual FoxPro. Viel zu oft sieht der Programmierer nur, daß der Datenbestand ja intern vorhanden ist und alle benötigten Informationen bereithält, und vergißt dann, daß der Anwender diese Informationen auch gerne auf verschiedenste Art und Weise auswerten möchte.

Leider ist der Report Designer von Visual FoxPro noch ein Überbleibsel aus der Version 2.x. Das bedeutet, daß er nicht wirklich in das Eventmodell, und auch nicht in das Objektmodell eingebunden ist (es sei denn, Sie verwenden GenRepoX). Die einzigen Neuerungen beschränken sich auf eine leicht veränderte Benutzerführung mit Drag&Drop, mit Popup-Menüs, die mit der rechten Maustaste aktiviert werden, und mit Toolbars. Ausserdem wurden einige kleine Zusätze in den REPORT-Befehl integriert. Z.B. können Sie nun in eine ASCII-Datei drucken, oder einen nicht-modale Vorschaudruck ausführen.

Die Stärken des Reportwriters liegen eindeutig in dessen Einfachheit. Man kann es fortgeschrittenen Anwendern und Powerusern durchaus zutrauen, eigene Reports zu erstellen, bzw. existierende Reports abzuändern.

Glücklicherweise ist der Report Designer das einzige der Powertools, das auch dem Enduser zur Verfügung steht.

Anmerkung: Als Powertool bezeichnet man den Formular Designer (MODI SCREEN xxx/ MODI FORM xxx), den Klassen Designer (MODI CLASS xxx), den Menü Designer (MODI MENU xxx) und den Report Designer (MODI REPO xxx).

Gibt man dem Anwender die Möglichkeit, Reports zu erstellen oder abzuändern, kann es sogar von Vorteil sein, daß keine Objektorientiertheit zur Verfügung steht. Denn dieses Feature könnte das Tool unter Umständen zu kompliziert machen. Dies soll jedoch nicht darüber hinwegtäuschen, daß dies eine eindeutige Schwäche des Reportgenerators ist.

GenRepoX

Hinweis: Zu dem Zeitpunkt, zu dem diese Konferenzunterlagen verfaßt wurden, befand sich die neue Version (2.0) von GenRepoX noch im Betatest. Es könnte daher sein, daß sich einige Funktionen oder Befehle ändern, bzw. neue hinzukommen. Sollte dies der Fall sein, und GenRepoX nicht wie erwartet reagieren, können Sie neuere Informationen der GenRepoX-Dokumentation entnehmen.

GenRepoX reiht sich natlos in die Reihe der existierenden PowerTool-Extender (GenScrnX und GenMenuX) ein. Dies wird für den Anwender von GenRepoX vor allem darin sichtbar, daß die Syntax von GenRepoX der von GenScrnX und GenMenuX sehr ählich ist.

Die meisten GenRepoX-Befehle werden direkt in das Komentar-Snippet des jeweiligen Objektes geschrieben und fangen mit *: an. Möchten Sie z.B. ein Report-Objekt unterstrichen darstellen, so können Sie in das Kommentarsnippet des jeweiligen Objektes *:UNDERLINE schreiben...

Zum Unterschied zu Masken und Menüs gibt es bei Reports keinen Generierungsprozess. Dies bedeutet, daß GenRepoX "On the Fly", also zur Laufzeit, arbeiten muß. Dies bietet jedoch auch erhebliche Vorteile. Die neuen objektorientierten Funktionen machen von dieser Fähigkeit reichlich Gebrauch.

Um GenRepoX zu verwenden, müssen Sie die aktuellen Befehle zum Ausführen von Reports durch GenRepoX-Routinen ersetzen. In der Praxis gestaltet sich dies äußerst einfach. Hier ein Beispiel:

Bisheriger Befehl:

Aufruf mit GenRepoX:

Wie Sie sehen, wird der Originalbefehl als Parameter übergeben. Sie müssen nur darauf achten, daß Sie das Programm GENREPOX.PRG in Ihr Projekt miteinbinden bzw. mitausliefern. Da GenRepoX PublicDomain ist, können Sie dies ohne weiteres machen.

Das Programm GenRepoX.prg kann mit 3 Parametern aufgerufen werden:

Dieser Parameter entspricht dem bisherigen Aufruf von Reports

Dieser Parameter bestimmt, ob der Report gedruckt werden soll, (.T.) oder ob nur ein Generierungslauf gestartet werden soll. (.F.) Dies ist vor allem dann sinnvoll, wenn Sie z.B. nur die Funktionen (siehe unten) neu generieren möchten.

(dient nur der Kompatibilität mit Version 1.x)

Manche Befehle für GenRepoX müssen in das globale Kommentarsnippet des Reports geschrieben werden. Da der normale Report-Editor keine Möglichkeit bietet, dieses Snippet zu editieren, kann dieses Snippet als Parameter übergeben werden. (Achten Sie darauf, daß alle einzelnen Befehlszeilen mit CHR(13) getrennt werden!)

Hinweis: In der Version 2.0 können all diese Befehle in der Kommentarzeile übergeben werden.

GenRepoX kopiert den gewünschten Report auf einen Temporärreport und verändert diesen nach eigenen Bedürfnissen. Dabei werden normalerweise keine Änderungen am Originalreport vorgenommen. (Ausnahme: siehe unten...) Die meisten Reports, die über GenRepox ausgeführt werden sollen, sind somit auch ohne GenRepoX ablauffähig.

Nachdem Sie GenRepoX aufgerufen haben, erscheint die Meldung "running GenRepoX..." am Bildschirm. Dies ist ein Hinweis, daß GenRepoX wie vorgesehen arbeitet. Diese Meldung erscheint nur in einer Entwicklungsumgebung und wird nicht angezeigt, wenn Ihr Programm als EXE läuft.

Nun wird der Report verändert und danach Ihr Befehl "durchgeschleift" und der Report ausgeführt. Dadurch wird 100%ige Kompatibilität zu FoxPro-Standardreports gesichert.

Im Normalfall wird an Ihren Originalreports keine Änderung vorgenommen. Es gibt hier nur eine Ausnahme: Funktionen. Programmieren Sie eine Funktion in einem Report, so wird diese On the Fly kompiliert und ausgeführt. Dies kann natürlich in einer EXE nicht mehr gemacht werden. Daher schreibt GenRepoX notwendige Informationen auch in den Originalreport. Die Informationen werden jedoch in Datenfeldern gespeichert, die in normalen Reports keine Funktion haben und somit völlig zweckfrei sind. Es ergeben sich somit keinerlei Kompatibilitätsprobleme. Sie müssen jedoch beachten, daß Reports in der Entwicklungsumgebung nicht ins Projekt eingebunden werden dürfen, da sie sonst schreibgeschützt sind. In der endgültigen Version dürfen Sie alle Reports jedoch wie gewohnt einbinden. Beachten Sie weiters, daß Funktionen in einem als EXE-File ausgelieferten Projekt nicht mehr verändert werden können. Sie können hier zwar die Kommentar-Snippets verändern, Sie werden jedoch keine Wirkung hervorrufen!

Das wichtigste neue Feature in Version 2.0 ist Objektorientiertheit, da diese zwar in Visual FoxPro, jedoch nicht in den Reports integriert wurde. Das Objektmodell von GenRepoX ist dem von Visual FoxPro sehr ähnlich. Sie können also Klassen definieren, Subklassen (mehrere Levels) erstellen, usw... GenRepoX bietet Ihnen sogar ein Feature, das von Visual FoxPro nicht unterstützt wird: Multible Inheritance. Dies bedeutet, daß eine Subklasse Eigenschaften von mehreren verschiedenen Klassen erben kann.

Hinweis: Die Objektorientiertheit steht Ihnen sowohl in FoxPro 2.x als auch in Visual FoxPro zur Verfügung.

Ein Problem in diesem Objektmodell und der FRX-Struktur ist, daß manche Felder automatisch überschrieben werden, da sie entweder vom Report-Writer automatisch eingefügt werden, oder der Anwender keine Möglichkeit hat, gewisse Felder freizulassen. Das bedeutet, daß das Vererbungsmodell ausser Kraft gesetzt wird. Aus diesem Grunde stellt GenRepoX Befehle zur Verfügung, um diese Felder nachträglich wieder zu löschen, und das Objektmodell funktioniert somit wieder. (Siehe auch: *:CLEAR_xxx - Befehle)

Dies ist ein sehr wichtiges Feature von GenRepoX. Das FoxPro-interne Objektmodell stellt dieses Feature nicht zur Verfügung.

Multible Inheritance stellt wohl den meistdiskutierten Punkt der objektorientierten Welt dar. Das Problem ist, daß klar definierte Dinge plötzlich verschwimmen. Man weiß z.B. nicht, welche Klasse die wirkliche Elternklasse ist, usw... Sollten Sie also der Meinung sein, Multible Inheritance hat mehr Nach- als Vorteile: Ignorieren Sie dieses Feature einfach.

Das Prinzip der mehrfachen Vererbung ist einfach. An Stelle einer *:AS_CLASS-Definition verwenden Sie einfach mehrere. Sie könnten z.B. eine Klasse haben, in der Sie ein bestimmtes Datenfeld definieren. In einer zweiten Klasse definieren Sie eine Print-When-Bedingung. Eine dritte Klasse erbt nun die Eigenschaften beider Klassen. Dabei ist die Klasse, die zuerst aufgeführt wird, die sogenannte "führende" Klasse. In unserem Beispiel würde die Klasse, die das Feld definiert, zuerst aufgerufen und danach die Print-When-Klasse. Sollte die Feld-Klasse jedoch auch eine Print-When-Bedingung haben, gilt diese Bedingung bereits als überschrieben, wenn die eigentliche Print-When-Klasse vererbt wird, und somit kann die Vererbung von der zweiten Klasse nicht mehr durchgeführt werden.

Eine Befehlsübersicht

Es gibt verschiedene Arten von GenRepoX Befehlen. Manche werden im Kommentarfeld des jeweiligen Objektes eingetragen und betreffen nur das jeweilige Feld, andere werden in das globale Kommentarsnippet des Reports geschrieben und beeinflussen den gesamten Report. Da das Eintragen von Kommentaren in das globale Kommentarfeld sehr umständlich ist, kann in der neuen Version (2.0) das komplette Kommentarsnippet in die Befehlszeile geschrieben werden. Das würde dann folgendermaßen aussehen:

Dieser Befehl sortiert alle Felder, die als Parameter genannt werden, in der Reihenfolge, in der sie angeführt werden. Die Namen der angegebenen Felder beziehen sich auf die mit *:DEFOBJ definierten Objekte.

Dieser Befehl definiert, in welcher Spalte das erste Feld einer Feldsortierung (*:SORTORDER) erscheint. Bei den zu verwendenden Werten handelt es sich um die Report-internen Maßeinheiten. Voreingestellt ist hier der Wert 1500.

Dieser Befehl definiert, wie groß der Zwischenraum zwischen den einzelnen sortierten Feldern sein soll. Bei den zu verwendenden Werten handelt es sich um die Report-internen Maßeinheiten. Voreingestellt ist hier der Wert 200.

Dieser Befehl kann an Stelle von *:SORTORDER verwendet werden. Der Unterschied besteht darin, daß mit dem Befehl *:SORTORDER die Sortierreihenfolge bereits durch den Befehl fix festgelegt wird. Der Befehl *:SORTORDER hat also nur dann Sinn, wenn das gesamte Kommentarsnippet als Parameter übergeben wird.

Mit dem Befehl *:DOSORT können die Felder direkt aus GenRepoX heraus verändert werden. Wird dieser Befehl ohne Parameter verwendet, wird das GenRepoX-interne Sortierprogramm gestartet. Gibt man einen Parameter an, so wird das als Parameter genannte Programm aufgerufen. Bei diesem Programm muß nur darauf geachtet werden, daß die Feldreihenfolge in eine Variable Namens "_grx_fld_sort" abgestellt wird. Diese Variable ist bereits vordefiniert und wird fix von GenRepoX vorgegeben. In dieser Variable müssen die Feldnamen so abgestellt werden, wie Sie auch als Parameter des Befehles *:SORTORDER benutzt werden.

Dieser Befehl vergrößert den Seitenkopf um x Zentimeter und verschiebt alle Objekte um x Zentimeter nach unten. Das ist z.B. hilfreich, wenn Sie nicht wissen, wie groß der Briefkopf Ihres Kunden ist, oder Ihre Kunden unterschiedlich große Briefköpfe haben. In diesem Fall können Sie die Größe des Briefkopfes als Parameter übergeben und Ihre Reports sind für jeden Kunden wie maßgeschneidert.

Anmerkung: Soll es sich bei x nicht um Zentimeter, sondern um Zoll handeln, können Sie das zusätzliche Schlüsselwort Inches angeben.

Das definiert eine Standardklassenbibliothek. Sie können beliebig viele Standardbibliotheken definieren. Die Klassenbibliothek muß eine gültige Tabelle des FRX-Formates sein. Sie können ihr jedoch einen beliebigen Namen geben.

Anmerkung: Wenn Sie die OF-Direktive im *:AS_CLASS-Befehl verwenden, ist es unnötig, eine Klassenbibliothek zu definieren.

 

Löscht das Objekt, während der Report generiert wird...

Löscht das Objekt, nachdem der Report generiert wurde. Verwenden Sie *:DELOBJ für Objekte, die Sie während des Generierens brauchen, die jedoch nicht im Report erscheinen sollen...

Fügt ein Unterstreichen-Attribut der momentanen Schriftart zu.

Ermöglicht ein Verwenden aller möglichen Farbwerte (von 1-255) Syntax: "*:RGB_COLOR 101,102,103,104,105,106"

Generiert eine Klasse, die die PrintWhen-Klausel des aktuellen Objektes enthält (auch die Remove-Line Anweisungen...)

Wendet eine definierte When-Klasse auf dieses Objekt an. Übernommen werden alle PrintWhen-Einstellungen... (auch die Remove-Line Anweisungen...)

Hier können vordefinierte Werte eingesetzt werden.:

Generiert eine Klasse, die die Expression-Klausel des aktuellen Objektes enthält.

Wendet eine definierte Expression-Klasse auf dieses Objekt an. Übernommen werden alle Expression-Einstellungen.

Generiert eine Klasse, die die Picture-Klausel des aktuellen Objektes enthält.

Wendet eine definierte Picture-Klasse auf dieses Objekt an. Übernommen werden alle Picture-Einstellungen.

Über diese Funktion wird eine Funktion generiert. Diese Funtion wird in eine GenRepoX - FunktionsLibrary Aufgenommen. Diese wird "On-The-Fly" erstellt und ausgeführt.

Wenn Sie mit FoxPro 2.x arbeiten ist es wichtig zu wissen daß GenRepoX keine Procedurefiles setzt. Sie können also weiterhin Ihre eigenen Procedurefiles verwenden (in der Dokumentation von GenRepoX 1.x wurde fälschlicherweise anderes behauptet).

Zeigt das Ende einer Funktion an. Dieses Ende-Zeichen muß nicht unbedingt gesetzt werden, wenn nach dieser Funktion keine Kommentare mehr kommen.

Über diesen Befehl kann einem Objekt ein eindeutiger Name zugewiesen werden. Dieser Name wird dann z.B. mit *:POSOVER angesprochen.

Weiters definieren Sie mit diesem Befehl einen Objektnamen für den PTX-Editor. Wird der Editor aufgerufen, und diese Definitionen existieren nicht, so werden diese automatisch generiert.

Mit diesem Kommando kann man einen Quasi-Detail-Bereich z.B. in einen Gruppenfuß einfügen. Bei diesem Befehl handelt es sich um den Detail-Extender. Bitte beachten Sie, daß sich dieser Detail-Bereich nicht über mehrere Seiten erstrecken kann!

Mit diesem Kommando kann ein Feld auf Grund einer Bedingung unterschiedlich eingefärbt werden. Weiters kann der gewünschte Font definiert werden.

Alle Objekte, die diese Direktive enthalten, können nachträglich umsortiert werden. Ist ein Objekt-String übergeben worden, und scheint ein definiertes Objekt nicht in der Liste auf, so wird dieses vom aktuellen Report entfernt.

Dieser Befehl positioniert ein Objekt genau über dem angegebenen Objekt, das vorher mit *:DEFOBJ definiert wurde...

 

Das definiert, daß das aktuelle Objekt eine Subklasse der Klasse ClassName ist. Haben Sie keine Klassenbibliothek mit *:CLASSLIB definiert, müssen Sie auch den Namen der Klassenbibliothek (FRX-File, in dem die Klasse definiert wurde) angeben. Um eine Klasse als solche zu erkennen, muß sie mit *:CLASS definiert werden.

Alle Methoden und Eigenschaften werden vererbt, so lange Sie sie nicht überschreiben. Haben Sie z.B. ein Picture-Statement in einer Klasse, werden alle Subklassen dieses Statement erben, so lange Sie nicht einen anderen Wert in dieser Subklasse definieren. Das ist dasselbe Verhalten wie in Visual FoxPro selbst. Möchten Sie mehr über OOP wissen, können Sie dies in einem der unzähligen OOP-Büchern nachlesen.

Anmerkung: GenRepoX unterstützt mehrfache Vererbungsschritte. Das bedeutet, Sie können eine Subklasse einer Klasse erstellen, und diese Klasse hat wiederum Subklassen, usw... Es gibt keine Einschränkung in der Anzahl der Subklassen-Schritte.

Anmerkung: Sie können mehr als ein *:AS_CLASS - Statement pro Objekt verwenden. In diesem Fall erbt das Objekt die Eigenschaften mehrerer Elternklassen. Das nennt man multible Inheritance.

Mit diesem Befehl definieren Sie eine Klasse. Dies ist der Name, mit dem eine Klasse aus Subklassen angesprochen werden kann.

Bei dem Report, in dem die Klasse gespeichert wird, handelt es sich um eine Klassenbibliothek. Bei dem Objektmodell, das GenRepoX verwendet, bedeutet dies jedoch nicht, daß eine Klassenbibliothek nicht auch gleichzeitig ein Report sein kann. Sie könnten also ein Feld, das in irgend einem Report verwendet wird, nachträglich zur Klasse und den Report zur Klassenbibliothek machen und den Report dennoch ganz normal ausdrucken.

Dieser Befehl löscht alle Expression-Einträge eines Objektes. Dies ist vor allem bei Klassen sinnvoll, da Sie automatisch den Expression-Wert in Elternklassen überschreiben, wenn es in diesem Feld einen Eintrag gibt. Leider macht es der Dialog des Report-Writers unmöglich, dieses Feld leer zu lassen. Der Eintrag würde also immer überschrieben. Verwenden Sie diesen Befehl, wird die Expression jedoch gelöscht, und der Vererbung steht nichts mehr im Wege.

Dieser Befehl löscht den Eintrag der Schriftart. Für mehr Informationen siehe *:CLEAR_EXPRESSION

Dieser Befehl löscht den Eintrag für die Schriftgröße. Für mehr Informationen siehe *:CLEAR_EXPRESSION

 

Dieser Befehl löscht den Eintrag im Schriftstil-Feld. Für mehr Informationen siehe *:CLEAR_EXPRESSION

Dieser Befehl löscht alle Informationen über Schriftart, -stil und -größe. Für mehr Informationen siehe *:CLEAR_EXPRESSION

Die Version 2.0 wird auch Events unterstützen. Dieses Feature steht jedoch zum Zeitpunkt des Erstellens dieser Unterlagen noch nicht zur Verfügung. Aktuellere Informationen können Sie der Dokumentation entnehmen.

Die Bedingung, die in 'Variablenname' steht, wird ausgewertet und eingesetzt. (Hier erfolgt eine EVALUATION!)

Dieser Operator referenziert eine Eigenschaft in der Elternklasse. Sie können ihn verwenden, wenn Sie einen Eintrag nicht überschreiben, sondern ergänzen möchten.

Sie können diesen Operator in jedem Text- und Memofeld verwenden. Im Gegensatz zum Objektmodell von Visual FoxPro kann dieser Operator nicht nur in Methoden, sondern auch in Properties verwendet werden.

 

Die FRX - Struktur

 

Diese Beschreibung der FRX-Dateistruktur erhebt keinen Anspruch auf Vollständigkeit. Sie ist jedoch eine wertvolle Hilfe um die Interna von Reports zu erkunden.
Feldname Beschreibung
PLATFORM Platform, für die dieses Feld Gültigkeit hat, z.B. WINDOWS oder UNIX
UNIQUEID Dies ist ein eindeutiger Name, der jedem Datensatz in der Reportdatei zugewiesen wird. Dies hat jedoch keine weitere Bedeutung. Wenn Sie per Hand Sätze in die Reportdatei einfügen, sollten Sie lediglich darauf achten, daß dieser Wert wirklich eindeutig ist
TIMESTAMP Dieser Wert läßt Rückschlüsse auf das Erstellungsdatum des Datensatzes zu. Das hat jedoch keine weitere Bedeutung.
OBJTYPE Das ist das erste wirklich interessante Feld. Es enthält nämlich Informationen über die Art der gespeicherten Information. Eine kurze Beschreibung der möglichen Werte:

1 = Beschreibungssatz der in jedem Report vorkommt

5 = Fixer Text

6 = Linie

7 = Rechteck oder abgerundetes Rechteck (Kreis)

8 = Datenfeld

9 = Dieser Datensatz enthält Informationen über einen Bereich, z.B. den Detailbereich oder einen Gruppenkopf, usw...

17 = Grafik oder OLE-Object

18 = Berichtsvariable

23 = Dieser Datensatz enthält Default-Werte für den Report, z.B. die Schriftgröße und die Schriftart

25 = Das ist das DataEnvironment (nur in VFP)

26 = Das ist eine Tabelle (Cursor) oder eine Relation im DataEnvironment (nur in VFP)

OBJCODE Dieses Feld hat unterschiedliche Bedeutungen, abhängig von OBJTYPE. Die wichtigsten Codes stehen in Relation zum Objekttype 4, dann haben die Codes folgende Bedeutung:

0 = Reporttitel

1 = Seitenkopf

3 = Gruppenkopf

4 = Detailbereich

5 = Gruppenfuß

7 = Seitenfuß

8 = Summenbereich

NAME Auch die Information, die dieses Feld enthält, ist abhängig vom aktuellen Objekt. Handelt es sich um ein OLE-Feld oder um eine Grafik, enthält dieses Feld den Datei- bzw. Feldnamen des auszugebenden Objektes. Handelt es sich um das DataEnvironment, eine Tabelle oder eine Relation, so enthält dieses Feld entweder „DataEnvironment", „Cursor" oder „Relation".
EXPR Auch der Inhalt dieses Feldes ist abhängig vom Objekttyp. Es kann z.B. den Feldnamen eines normalen Ausgabefeldes enthalten, den auszugebenden Text eines Label-Elements oder die Properties einer Tabelle im DataEnvironment.
VPOS Dieses Feld enthält Informationen über die vertikale Position des aktuellen Objektes.

Dies ist die absolute Position des Objektes, wie es am Bildschirm erscheint. Dabei ist es wichtig zu wissen, daß auch die Balken, die die einzelnen Detailbereiche trennen, mitgezählt werden. Haben wir z.B. einen Seitenkopf mit einer Höhe von 0 (also ganz oben) und ein Feld, das (über den Daumen gemessen) 2 cm unterhalb des Seitenkopf-Balkens positioniert ist, so hat dieses Feld nicht die 2cm-Position, sondern 2cm+Höhe des Balkens.

Bei den Werten, die in diesem Feld gespeichert werden, handelt es sich um tausendstel Milimeter.

HPOS Dies ist die horizontale Position des aktuellen Objektes.
HEIGHT Das ist die Höhe des Objektes.
WIDTH Das ist die Breite des Objektes.
PICTURE Deses Feld enthält die Style-Klausel des Ausgabefeldes. Dieses Feld ist kompatibel zu den PICTURE-Klauseln der @SAY-Befehle.
COMMENT Das ist das Kommentarfeld des jeweiligen Objektes.
ENVIRON Dieses Feld besagt ob die aktuelle Systemumgebung mitgespeichert wird. (nur FoxPro 2.x)
FILLCHAR Dieses Feld gibt uns Auskunft darüber, um welchen Feldtyp es sich bei einem Text-Ausgabefeld handelt. Z.B. „C" für Character, „N" für Numeric, usw...
TAG Dieses Feld enthält unterschiedliche Daten, abhängig vom Datensatztyp. Im ersten Datensatz wird binäre Information über den Druckertreiber gespeichert. Diese binäre Information entspricht der C-Struktur, die an den Druckertreiber übergeben wird.

In den weiteren Datensätzen kann in diesem Feld Klartextinformation über den aktuellen Satz gespeichert sein, z.B. „PHEAD", wenn es sich um den Seitenkopf handelt.

TAG2 Auch dieses Feld enthält binäre Informationen über den Druckertreiber.

Anmerkung: Wenn Sie Probleme mit dem Druckertreiber haben, können Sie die Felder TAG und TAG2 löschen. FoxPro wird dann den Standarddruckertreiber verwenden.

PENRED, PENGREEN, PENBLUE Diese Felder enthalten Informationen über die Vordergrundfarbe des aktuellen Objektes (RGB-Werte). In FoxPro 2.x stehen uns im ReportWriter nur 16 verschiedene Farben zur Auswahl. Sie können jedoch jederzeit weitere Farben direkt hier eintragen.
FILLRED, FILLGREEN, FIILLBLUE Diese Felder enthalten die Werte für die Hintergrundfarben.
PENSIZE Hier wird die Linienstärke gespeichert.
PENPAT Das ist der Linienpattern.
FILLPAT Das ist der Füllpattern.
FONTFACE Das ist der Schriftname.

Anmerkung: Verwenden Sie ausschließlich TrueType-Fonts in Ihren Reports! Alle anderen Fonts bringen die merkwürdigsten Ausdrucke zu Tage, und zwar meistens dann, wenn der Report das erste Mal beim Kunden gedruckt wird. Wenn Sie nur Reports für sich selbst oder für einen speziellen einzelnen Kunden erstellen, können Sie auch Druckerfonts verwenden.

FONTSTYLE Das ist der Schriftstil gespeichert in Codes. Die einzelnen Codes bedeuten folgendes:

0 = Normal

1 = Fett

2 = Kursiv

3 = Fett und Kursiv

4 = Unterstrichen

5 = Fett und Unterstrichen

6 = Kursiv und Unterstrichen

7 = Fett, Kursiv und Unterstrichen

Anmerkung: Die Unterstrichen-Attribute können Sie nicht über den ReportWriter aktivieren, sondern nur direkt hier eintragen.

FONTSIZE Das ist die Schriftgröße
MODE Dieses Feld legt fest, ob das Objekt durchsichtig ist, oder nicht.

1= Transparent

2 = Undurchsichtig

Anmerkung: In FoxPro 2.6 gab es öfters das Problem, daß Felder als schwarze Balken ausgedruckt wurden. Dies an einem Bug in FoxPro. Als Workaround kann man einfach dieses Feld auf 1 (transparent) setzen, und die Ausgabe funktioniert wie gewünscht.

RULER, RULERLINES, GRID, GRIDV, GRIDH Dises Felder geben an, ob Lineale angezeigt werden sollen, ob ein Grid angezeigt werden soll, und wie grob das Grid sein soll. Diese Felder haben jedoch keinen direkten Einfluß auf den Ausdruck.
FLOAT, STRETCH, STRETCHTOP, TOP, BOTTOM Diese Felder geben an, ob das aktuelle Objekt mit im Detailbereich wandern soll, wenn er wächst (FLOAT = .T.), ob sich das Feld dehnen soll, wenn der Detailbereich wächst (STRETCH = .T.), ob sich das Feld dehnen und die obere Position beibehalten soll (STRETCHTOP = .T.) und ob die Feldposition relativ zum oberen Rand des aktuellen Bereiches gemessen wird (TOP = .T.) oder vom unteren Rand (BOTTOM = .T.).
NOREPEAT Wenn dieses Feld auf .T. gesetzt ist, bedeutet dies, daß das aktuelle Objekt nur einmal gedruckt wird und Wiederholungen unterdrückt werden.
RESETRPT Wenn dieses Feld auf .T. gesetzt wird, bedeutet dies, daß nach dem Ausdruck dieses Objektes der Report zurückgesetzt wird.
PAGEBREAK .T. bedeutet, daß nach dem Ausdruck dieses Objektes ein Seitenumbruch ausgelöst wird.
COLBREAK .T. bedeutet, daß nach dem Ausdruck dieses Objektes ein Spaltenumbruch ausgelöst wird.
RESETPAGE Dieses Feld gibt Auskunft darüber, ob nach dem Druck dieses Objektes ein Seitenreset (_PAGENO=1) durchgeführt wird.
GENERAL Gibt Auskunft darüber, wie sich eine Grafik dehnt.

0 = Bild abschneiden

1 = Bild dehnen, Proportionen jedoch beibehalten

2 = Bild dehnen und dabei den Ramen ausfüllen

SPACING Definiert den Zeilenabstand in Textbereichen

0 = normaler Abstand (1 Zeile)

1 = 1 ½ Zeilen

2 = 2 Zeilen

DOUBLE Soll eine Grafik die aus einem General-Feld kommt zentriert gedruckt werden? (.T. = Ja, .F. = Nein)
SWAPHEADER Steht dieses Feld auf .T., bedeutet das, daß dieser Header auf eine neue Seite gedruckt wird.
SWAPFOOTER Steht dieses Feld auf .T., bedeutet das, daß dieser Footer auf eine neue Seite gedruckt wird.
EJECTBEFOR Dies legt fest, ob vor dem Report ein Seitenumbruch ausgeführt werden soll.
EJECTAFTER Dies legt fest, ob nach dem Report ein Seitenumbruch ausgeführt werden soll.
PLAIN Dieses Feld wird nur in DOS und UNIX verwendet und gibt Auskunft darüber, ob der Seitenkopf nur auf Seite 1 gedruckt wird, oder immer.
SUMMARY Dieses Feld wird nur in DOS und UNIX verwendet und definiert die Art der Summierung.
ADDALIAS Dies legt fest, ob als Stabnard der Alias vor die Feldnamen gesetzt werden soll, oder nicht.
OFFSET Dieses Feld erfüllt verschiedenste Funktionen. In DOS und UNIX wird es z.B. dazu verwendet, Report- und Bandinformationen zu speichern.

Die Verwendung dieses Feldes hängt stark vom Feldtypen ab.

Grafik: Bei Grafiken wird dieses Feld dazu verwendet, die Grafiksource zu defineren (Bitmap/ General)

Text: Die Ausrichtung des Textes wird hier gespeichert. Achtung! Das gilt nicht für Felder!

Vierecke: Hier wird der Radius der Abrundung gespeichert.

Linien: Handelt es sich um eine Horizintale, oder um eine vertikale Linie?

TOPMARGIN Dieses Feld wird in DOS und UNIX dazu verwendet, um den oberen Rand zu definieren. Weiters definiert es in der Windows- und Mac-Welt den oberen Rand von Datenfeldern.
BOTMARGIN Dieses Feld wird in DOS und UNIX dazu verwendet, um den unteren Rand zu definieren.
TOTALTYPE Dieses Feld enthält codierte Information über die Art der Berechnung, die durchgeführt werden soll.

0 = keine Berechnungen

1 = Anzahl

2 = Summierung

3 = Durchschnitt

4 = Kleinstes

5 = Größtes

6 = Standard Deviation

7 = Varianz

RESETTOTAL Dieser Code gibt an, wann eine Berechnung zurückgesetzt werden soll.
CURPOS Ist dieses Feld auf .T. gesetzt (im ersten Datensatz), wird im Statusbar die aktuelle Cursorporition angezeigt. Das funktioniert natürlich nur in Windows bzw. am Mac, und da auch nur im Editiermodus.
SUPALWAYS Wenn dieses Feld auf .T. gesetz ist, wird die Zeile in der sich das Objekt befindet nicht gedruckt, sofern die Zeile völlig leer ist.
SUPOVFLOW Wenn dieses Feld auf .T. steht, wird das Objekt gedruckt, wenn der Detailbereich auf eine neue Seite gewechselt hat (= erste Detailzeile in einer neuen Seite).
SUPRPCOL Wenn dieses Feld nicht auf 0 steht, wird das Objekt im ersten ganzen Bereich einer neuen Seite gedruckt.
SUPGROUP Wenn dieses Feld nicht 0 ist, wird das Objekt gedruckt, wenn die Gruppe wechselt. Um welche Gruppe es sich handelt, wir durch die Zahl festgelegt.
SUPVALCHNG Ist dieses Feld auf .T. wird das Feld nur gedruckt wenn sich sein Inhalt ändert.
SUPEXPR Dieses Feld enthält die Print-When-Bedingung.
USER Dieses Feld kann für beliebige zusätzliche Informationen verwendet werden.

 

Die hier beschriebenen Dinge sind größtenteils undokumentiert und können daher von Microsoft jederzeit geändert werden. Weiters unterscheiden sich viele der Felder in den verschiedenen Entwicklungsumgebungen (DOS, Windows, UNIX und Mac). Das Entwicklerhandbuch von FoxPro gibt Auskunft darüber welche Felder in welchen Entwicklumgsumgebungen verwendet werden. Leider sind die Feldbezeichnungen nicht sehr aussagekräftig, oder hätten Sie gewußt, daß der Radius der Vierecksabrundungen in Offset gespeichert wird, wärend das selbe Feld bei Linien dazu verwendet wird, den Linienverlauf zu speichern?