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.
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.
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.
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!
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).
Die Klassenbibliothek GenRepoX.VCX enthält (unter anderem) folgende Klassen:
Alle anderen Klassen sind für interne Zwecke reserviert.
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.
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.
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.
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 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.
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)
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.
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”)
.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. |
.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. |
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. |
*: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.:
|
*: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. |
{{&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. |
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,
|
SPACING |
Definiert den Zeilenabstand in Textbereichen: 0 = normaler Abstand
(1 Zeile) |
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. |
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. |