Session D-REPO

Der Report Designer und
Visual GenRepoX

Markus Egger
EPS-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.

Der Report Designer als Endusertool

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.

Visual GenRepoX

Hinweis: Zu dem Zeitpunkt, zu dem diese Konferenzunterlagen verfaßt wurden, befand sich die neue Version (3.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.

Was ist Visual GenRepoX?

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

Die meisten GenRepoX-Befehle werden direkt in das Kommentar-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 von Masken und Menüs gibt es bei Reports keinen Generierungsprozess. Dies bedeutet, daß Visual 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.

Anmerkung: Während Visual GenRepoX Visual FoxPro 5 voraussetzt, können Sie GenRepoX 2.x auch in FoxPro 2.x für DOS, Windows und Mac verwenden. Die Syntax zur Verwendung von GenRepoX 2.x unterscheidet sich jedoch stark von der neuen Syntax. Nähere Hinweise dazu entnehmen Sie bitte der GenRepoX Dokumentation.

Einige Hinweise zur Arbeitsweise

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 ausgedruckt. Dabei 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!

Was ist neu in Visual GenRepoX 3.0?

Visual GenRepoX 3.0 stellt erstmals Reportobjekte in Visual FoxPro vor. An Stelle der bisher üblichen Befehle (REPORT FORM...) werden nun einfach Reportobjekte instanziiert. Hier ein Beispiel:

oReport = CreateObject( “MyReport” )

Dieser Report würde nun als selbständiges Objekt im Speicher von Visual FoxPro leben. Reportobjekte können auch innerhalb anderer Container leben. Ein typischer Container für Reportobjekte wären Formulare:

oForm = CreateObject( “Form” )
oForm.AddObject( “oReport”, “MyReport” )

Der Ausdruck eines Reportes kann über die Print-Methode erfolgen:

oReport.Print

In diesem Fall würde ein Dialog angezeigt werden, in dem man auswählen kann, ob der Report auf den Drucker ausgegeben, oder ob eine Vorschau angezeigt werden soll. Das kommt daher, daß wir noch nicht definiert haben, wohin der Report geschickt werden soll. Dies können wir über das Output Property machen:

oReport.Output = 1

1 = Ausgabe auf den Drucker. 2 hingegen wäre “Druckvorschau”. Ausserdem könnten Sie hier einen Dateinamen angeben. In diesem Fall würde in die angegebene Datei gedruckt werden.

Ebenso einfach wie gedruckt kann ein Report modifiziert werden:

oReport.Modify

Eine nähere Beschreibung aller Methoden und Properties können Sie der Visual GenRepoX Dokumentation oder diesen Unterlagen (siehe unten) entnehmen.

Natürlich können Reportobjekte/ Reportklassen auch gesubclassed und vererbt werden. Ausserdem ist es wichtig zu wissen, daß ein Reportobjekt ein Container ist. In diesem Container können Kindobjekte (wie z.B. GenRepoX-Treiber) leben. Damit entfällt das umständliche Registrieren von Treibern. Man dropped diese einfach in einem Reportobjekt. Eine weitere Möglichkeit für Kindobjekte wären sogenannte “Scheduler”. Dies sind Timer die den Report zu bestimmten Zeiten drucken (siehe unten).

Objektorientierte Reports im Detail

Die Klassenbibliothek GenRepoX.VCX enthält (unter anderem) folgende Klassen:

Alle anderen Klassen sind für interne Zwecke reserviert.

Die Klasse cReportX

Das ist die eigentliche Report-Klasse. Eine genaue Beschreibung Ihrer Poperties und Methoden finden Sie entweder in der Visual GenRepoX Dokumentation oder in diesen Unterlagen (siehe unten).

Hinweis: Zu dem Zeitpunkt, zu dem diese Unterlagen verfaßt werden, befindet sich Visual GenRepoX 3.0 noch in einer Beta-Phase. Ich empfehle daher die Dokumentation des fertigen Produktes zu lesen.

Natürlich verwendet auch Visual GenRepoX 3.0 die altbekannten FRX-Dateien, um das Report-Layout zu definieren. Würde dies nicht gemacht werden (so wie dies in sehr frühen Beta-Versionen der Fall war), käme es zu Problemen mit der Kompatibilität. Diese Layout-Files sind jedoch nur ein Teil der Reportobjekte. Sie werden über das Property ReportName an das eigentliche Objekt gebunden.

Ein Beispiel

Erstellen Sie eine Subklasse der Klasse cReportX. Tragen Sie im Property ReportName einen beliebigen Namen für Ihr Reportlayout ein. Instanziieren Sie diese Klasse:

oReport = CreateObject( “MyReport” )

Editieren Sie nun das Layout:

oReport.Modify

Nun wird automatisch eine FRX-Datei (und natürlich auch eine FRT-Datei) mit dem von Ihnen vergebenen Namen kreiert. Denken Sie immer daran, daß diese Dateien auf Ihrer Festplatte existieren und auch mit Ihrer fertigen Applikation ausgeliefert werden müssen (entweder ins Projekt eingebunden, oder als zusätzliche Dateien). Das Report-Layout wird weiterhin behandelt, wie wir das bereits gewohnt sind. Das Reportobjekt ist lediglich ein Wrapper um dieses Layout herum.

Nun können Sie diesen Report auch drucken:

oReport.Output = 2 && Preview
oReport.Print

Properties (wie z.B. Output) sollten normalerweise bereits in der Klasse gesetzt werden.

Treiber

Wie alle bisherigen Versionen von GenRepoX unterstützt auch Visual GenRepoX 3.0 zusätzliche Treiber. Bisher waren diese Treiber leider relativ umständlich zu installieren. Mit Visual GenRepoX gehört dieses Problem der Vergangenheit an. Um einen Treiber zu installieren, müssen Sie diesen lediglich in einem Reportobjekt droppen. Dies machen Sie am besten im Visual Class Designer.

Beispiel

Nehmen wir an, Sie haben einen bestehenden Report, den Sie nun mehrsprachig machen möchten. Um dies zu tun, fügen Sie einfach Ihrer Reportklasse den INTL-Treiber von Steven Black zu, und schon wird Ihr Report in der jeweiligen Landessprache erscheinen.

Scheduler

Scheduler ermöglichen es Ihnen, Reports zu bestimmten Zeiten zu drucken. Dies kann eine bestimmte Zeit an einem bestimmten Tag (Datum), eine bestimmte Zeit jeden Tag, ein bestimmtes Datum oder ein bestimmter Wochentag sein. Genauere Informationen zu den Schedulers können Sie der Visual GenRepoX Dokumentation entnehmen.

Objektorientiertheit in Reports

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 wenn Sie die Version 2.0 verwenden.

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)

Multible Inheritance/ Mehrfache Vererbung

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 (GenRepoX 2.0) und beeinflussen den gesamten Report oder stellen Properties des Report-Objektes dar.

Hinweis zur Version 2.0: Da das Eintragen von Kommentaren in das globale Kommentarfeld sehr umständlich ist, kann in der Version 2.0 das komplette Kommentarsnippet in die Befehlszeile geschrieben werden. Das würde dann folgendermaßen aussehen:

=GenRepoX(“REPORT FORM Test PREVIEW *:MOVEHEAD 10”)

Properties des GenRepoX Objektes

.AutoPrint = .T./.F.
Dieses Property definiert, ob ein Reportobjekt sofort nach dessen Instanziierung gedruckt werden soll (.T.) oder nicht (.F.).

.ClassLib = ClassLib1, ClassLib2,...

Das definiert eine Standardklassenbibliothek. Sie können beliebig viele Standardbibliotheken definieren (mit Kommas getrennt). 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.

.Commands = cCommand
In dieses Property können Sie zusätzliche Befehle für den Ausdruck des Reportes schreiben. Nähere Informationen können Sie der Visual GenRepoX 3.0 Dokumentation entnehmen.

.DoSort = .T./.F.

Dieses Property steht normalerweise auf .F.. Es kann jedoch auf .T. gesetzt werden und ersetzt somit den Eintrag im .SortOrder Property. Der Unterschied besteht darin, daß mit .SortOrder die Sortierreihenfolge bereits festgelegt wird. Das .SortOrder Property hat also nur dann Sinn, wenn man die zu sortierenden Felder bereits kennt.

Mit dem .DoSort Property können die Felder direkt aus GenRepoX heraus verändert werden. Dieses Property kooperiert mit dem .SortClass Property. In diesem Property wird definiert, welche Klasse als Dialog verwendet werden soll (siehe unten).

.For = cForCondition
Dieses Property entspricht der For-Klausel des REPORT FORM... Befehles.

.Heading = cHeading
Dieses Property entspricht der Heading-Klausel des REPORT FORM... Befehles.

.Modeless = .T./.F.
Dieses Property entspricht der Nowait-Klausel des REPORT FORM... Befehles. Dieses Property kann entweder auf .T. oder .F. gesetzt werden.

.MoveHead = nMoveBy
Dieses Property definiert, ob der Seitenkopf automatisch vergrößert werden soll. Dies ist vor allem dann sinnvoll, wenn man nicht weiß, wie viel Platz der Briefkopf verschiedener Kunden einnehmen wird. Die Verschiebung wird (sofern nicht in .MoveUnit anders angegeben) in cm definiert.

.MoveUnit = cm/inch
Normalerweise wird bei Verschiebungen des Briefkopfes (.MoveHead) eine cm-Einheit verwendet. Dies wird in diesem Property definiert. Man kann hier an Stelle von cm auch Inches (Zoll) angeben. Tragen Sie dazu einfach den String “Inches” in dieses Property ein.

.NoConsole = .T./.F.
Dieses Property entspricht der NoConsole-Klausel des REPORT FORM... Befehles. Dieses Property kann entweder auf .T. oder .F. gesetzt werden.

.NoEject = .T./.F.
Dieses Property entspricht der NoEject-Klausel des REPORT FORM... Befehles. Dieses Property kann entweder auf .T. oder .F. gesetzt werden.

.Output = 0,1,2 oder cDateiName

Dieses Property definiert, wohin ein Report gedruckt werden soll.

0 = Ein Dialog erscheint in dem man “Drucker” oder “Seitenvorschau” wählen kann.
1 = Drucker
2 = Seitenvorschau
cDateiName = Der Report wird in das angegebene File gedruckt.

.Plain = .T./.F.
Dieses Property entspricht der Plain-Klausel des REPORT FORM... Befehles. Dieses Property kann entweder auf .T. oder .F. gesetzt werden.

.Prompt = .T./.F.
Dieses Property entspricht der Prompt-Klausel des REPORT FORM... Befehles. Dieses Property kann entweder auf .T. oder .F. gesetzt werden.

.ReportName = cReportName
Dieses Property verweist auf das Layout-File des Reportes (FRX).

.Scope = cScope
Dieses Property entspricht der Scope-Klausel des REPORT FORM... Befehles.

.SortClass = ClassName, ClassLib
Dieses Property definiert, welche Klasse als Dialog für Feldsortierungen verwendet werden soll. Standard ist die Klasse cDoSort. Diese Klasse kann natürlich jederzeit gesubclassed oder vollständig ersetzt werden. Sollte die neue Klasse nicht im Suchpfad sein, so müssen Sie auch den Namen der Klassenbibliothek (vom Klassennamen mit einem Komma getrennt) eingeben.

.SortCol = nPos
Dieses Property 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.

.SortOrder = field1, field2, field3,...
Dieses Property definiert die Sortierreihenfolge für Felder/ Spalten. Einzelne Feldnamen werden, durch Kommas getrennt, in dieses Proeperty eingetragen. Die Namen der angegebenen Felder beziehen sich auf die mit *:DEFOBJ definierten Objekte.

.SortSpace = nSpace
Dieses Property 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.

.StandardPrinter = .T./.F.
Wenn Sie einen Report erstellen, merkt sich FoxPro, welchen Druckertreiber Sie dabei verwendet haben. Wird der Report dann auf einem anderen Drucker gedruckt, kommt es zu den unerfreulichsten Überraschungen. Setzen Sie dieses Property auf .T., wird diese Information jedoch nicht beachtet und statt dessen der aktuelle Standarddruckertreiber verwendet.

.Summary = .T./.F.
Dieses Property entspricht der Summary-Klausel des REPORT FORM... Befehles. Dieses Property kann entweder auf .T. oder .F. gesetzt werden.

.While = cWhileCondition
Dieses Property entspricht der While-Klausel des REPORT FORM... Befehles.

Methoden des GenRepoX Objektes

oReport::Print()
Druckt den Report auf das definierte Ausgabegerät (siehe auch .Output Property).

oReport::Modify()
Aktiviert den Report-Designer, mit dessen Hilfe Sie das Report-Layout editieren können.

oReport::Release()
Entfernt das Reportobjekt aus dem Speicher.

Verwendbare Befehle im Kommentar-Snippet:

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

*:DELOBJ
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...
*:UNDERLINE
Fügt ein Unterstreichen-Attribut der momentanen Schriftart zu.

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

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

*:USE_WHEN_CLASS

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.:

  • GRX_PageOne --> Nur auf Seite 1 drucken...
  • GRX_not_PageOne --> Auf Seite 1 nicht drucken...

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

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

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

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

*:FUNCTION

Ü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).

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

*:DEFOBJ

Ü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.

*:DETAIL DbfName [FOR Bedingung]
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!

*:IF_COLOR bedingung COLOR RGB(rot,grün,blau,rot,grün,blau)
FONT "Fontname", Fontsize STYLE "FontStyle"
Mit diesem Kommando kann ein Feld auf Grund einer Bedingung unterschiedlich eingefärbt werden. Weiters kann der gewünschte Font definiert werden.

*:SORTOBJ Objektname
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.

*:POSOVER Def-Objektname [LEFT | CENTER | RIGHT]
Dieser Befehl positioniert ein Objekt genau über dem angegebenen Objekt, das vorher mit *:DEFOBJ definiert wurde...

*:AS_CLASS ClassName [OF ClassLib] (neu seit Version 2.0)

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.

*:CLASS ClassName (neu seit Version 2.0)

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.

*:CLEAR_EXPRESSION (neu seit Version 2.0)
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.

*:CLEAR_FONTFACE (neu seit Version 2.0)
Dieser Befehl löscht den Eintrag der Schriftart. Für mehr Informationen siehe *:CLEAR_EXPRESSION

*:CLEAR_FONTSIZE (neu seit Version 2.0)
Dieser Befehl löscht den Eintrag für die Schriftgröße. Für mehr Informationen siehe *:CLEAR_EXPRESSION

*:CLEAR_FONTSTYLE (neu seit Version 2.0)
Dieser Befehl löscht den Eintrag im Schriftstil-Feld. Für mehr Informationen siehe *:CLEAR_EXPRESSION

*:CLEAR_FONTINFO (neu seit Version 2.0)
Dieser Befehl löscht alle Informationen über Schriftart, -stil und -größe. Für mehr Informationen siehe *:CLEAR_EXPRESSION

*:EVENT EventName (neu seit Version 2.0)
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.

 

Befehle, die Sie in den Picture- und Expression-Snippets verwenden können:

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

*:: (neu seit Version 2.0)
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. Dieser Operator kann 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.

Die hier beschriebenen Dinge sind größtenteils undokumentiert und können daher von Microsoft jederzeit geändert werden. Weiterhin 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?

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.