Session D-FORM

Der Formdesigner von
Visual FoxPro 3.0

Peter Herzog
Peter Herzog System & Organisation

EINLEITUNG

1. Der Formdesigner und dessen Verwendung

Der Formdesigner ist eine der zentralen Neuerungen von Visual FoxPro 3.0.

Wie unter den Version 2.x haben Sie die Möglichkeit Ihr Maskendesign am Bildschirm zu gestalten.

Der große Unterschied zur 2.x Version besteht allerdings darin, daß unter Visual FoxPro 3.0 die gesamte SCX-Datei sofort ausgeführt werden kann. Um dies zu verdeutlichen muß ich ein wenig weiter ausholen.

Bisher wurde eine Maske entweder handkodiert oder durch den Maskeneditor erstellt. Durch das visuelle Zusammenstellen von Elementen am Bildschirm wurde jedoch noch lange kein eigentlicher, ausführbarer Code generiert, sondern es wurden sogenannte „Metadaten" erstellt. Die Metadaten wurden in einer Datei mit der Endung .SCX abgelegt. Erst ein sogenannter Generator (GENSCRN.PRG) verwandelte aus den Metadaten echte Programme, die dann ausgeführt werden konnten. Die erzeugten Daten hatten die Endung *.SPR um sie von „normalen" Programmen unterscheiden zu können.

Im neuen Visual FoxPro ist man nun übergegangen, den Generationsprozess wegzulassen und es wurde möglich die Maske, heute Formular genannt, sofort wie ein Programm auszuführen.

Anlegen und Ändern eines Formulars geschieht durch die Befehle CREATE FORM <Formular> und MODIFY FORM <Formular>.

Wenn CREATE FORM verwendet wird, so wird ein bereits bestehendes Formular überschrieben. Bei MODIFY FORM wird ein bestehendes Formular geöffnet oder es wird automatisch ein neues Formular angelegt. Sobald das Fenster am Bildschirm erscheint, haben Sie die Möglichkeit neue Elemente einzugeben, bzw. anzulegen. Zusätzlich zum Eingabefenster erscheinen, je nach Systemeinstellung, zusätzliche Fenster.

gleichzeitig mit dem eigentlichem Fenster für das reine Editieren erscheint eine Toolbar, die bereits aus der Version 2.x bekannt ist, jedoch damals direkt im Editierfenster integriert war.

 

Die Toolbar zeigt nun Teils die gewohnten und Teils völlig neue Symbole, auf die ich hier näher eingehen möchte.

Der Pfeil zeigt an, daß Sie im Moment Objekte auf dem Fenster bewegen und verändern können.

Mit diesem Objekt können Sie selbstdefinierte „Visual Classes" zu Ihrer Maske zufügen, bzw. zwischen mehreren Form Controls wählen.

Diese drei Elemente entsprechen den @...SAY, @...GET und @...EDIT Befehlen und verhalten sich genauso wie unter der Version 2.x.

Dies entspricht einem 2.xer Pushbutton, wird jedoch nun CommandButton genannt.

Unter 2.x war es möglich mehrere PushButtons zu einer Reihe zusammenzufügen. Da diese Funktion bei einem CommandButton nicht mehr zur Verfügung steht, wurde die „Command Group" eingeführt. Dabei handelt es sich um ein Containerobjekt, welches mehrere CommandButtons beinhalten kann.

Der ehemalige Radiobutton ist nun zum Option Group geworden, reagiert jedoch genauso.

Die Checkbox oder Markierfeld hat sich ebenfalls nicht verändert. Es stellt nach wie vor einen Logischen Wert dar, der allerdings nun nicht mehr Ja oder Nein, sondern auch undefiniert beinhalten kann. Wie das obige Beispiel zeigt, ist die Checkbox an einen numerischen Wert gebunden, der im letzteren Falle eine 2 annimmt und somit undefiniert erscheint.

Die sogenannte Combobox ist ebenfalls aus der Version 2.x her bekannt, wurde jedoch um viele neue Features erweitert. Um nur ein einziges zu nennen, kann nun in dieser Combobox bereits editiert werden usw.

Dies ist die Listbox, die ebenfalls bereits bekannt ist, jedoch ebenfalls um eine Vielzahl an Möglichkeiten erweitert wurde. Unter anderem ist es nun möglich mehrere Spalten zu definieren usw.

Bei diesem Objekt handelt es sich um einen sogenannten Spinner, der eine Zahl hinauf oder hinunterzählen kann.

Die ist das Symbol für ein Gridobjekt, welches weiter unten beschrieben wird.

Ein Bildsymbol, mit dem man beliebige BMP-Files einbinden kann.

 

Hierbei handelt es sich um ein Timerobjekt, welches zur Laufzeit selbst nicht sichtbar ist und beliebig auf dem Formular plaziert werden kann. Durch die Properties kann definiert werden, daß nach Ablauf einer definierten Zeit ein FoxPro-Programm gestartet wird.

Dies ist das Pageframe-Objekt. Es handelt sich dabei um ein Containerobjekt, welches wiederum andere Objekte in sich tragen kann. Jede Seite (Page) dieses Objektes wird durch einen Klick auf dessen Reiter aktiviert. Die Anzahl der Seiten usw. kann natürlich frei definiert werden. Es gibt auch noch eine Seite, welches sozusagen darunter liegt. Jedes Objekt, welches auf der untersten Seite liegt, wird durch alle anderen Seiten hindurch angezeigt und ist auch anwählbar.

Bei diesen Objekten handelt es sich einerseits um freie OLE2-Objekte, die z.B. wie Paint vorhanden sein können, andererseits können Sie damit „gebundene OLE-OBJEKTE" in Ihre Maske einbringen. Vereinfacht gesagt, können Sie ein WinWord oder Excel in Ihrer Applikation laufen lassen, wobei die Daten aus einer Datenbank kommen.

Hierbei handelt es sich um einfach Linien oder um grafische Elemente.

Dieses Objekt ist ein Separator, der bei der Definition einer Toolbar mehrere Objekte voneinander trennen kann, damit sie nicht zu sehr aufeinanderkleben.

Beim ersten Symbol handelt es sich um den Builder-Lock, beim zweiten um den Button-Lock. Wird der Button Lock gedrückt, dann bleibt z.B. ein CommandButton aktiv und kann mehrmals in der Maske plaziert werden.

Jedes Element beinhaltet Properties und Methoden. Bei einem Property (Eigenschaft) handelt es sich um einen einstellbaren Wert, der z.B. das Aussehen eines Objektes beeinflußt. Oder z.B. einstellt, woher die Daten für dieses Objekt kommen sollen.

Bei Methoden handelt es sich um Aktionen die ausgelöst werden. Eine Methode eines CommandButtons wäre z.B. der einfache Klick darauf. Aber bereits ein darüberfahren mit der Maus kann eine solche Methode „abfeuern". Man spricht hierbei um die Events. Sollte das Eigenschaftenfenster nicht offen sein, so kann es geöffnet werden, in dem man mit der rechten Maustaste auf das Formular klickt und dann dementsprechend „Eigenschaften..." anklickt. Das Eigenschaftenfenster besteht aus mehreren Elementen

Hier können Sie die gesamte Baumstruktur Ihrer Maske betrachten und sich ein spezielles Element auswählen.

Das Pinnadelsymbol kann zwei verschiedene Zustände einnehmen. Das erste zeigt an, daß das Property sozusagen angesteckt ist. In diesem Falle bleibt das Fenster immer im Vordergrund. Diese Funktion entspricht dem „AlwaysOnTop" Property und kann natürlich auch selbst erzeugt werden.

Dieses Symbol startet einen Builder, der einem beim Erzeugen von Elementen unterstützt. Die Besonderheit an solchen Buildern ist, daß man sie selbst mit normalem FoxPro-Programmcode schreiben kann.

Es wird hier nicht näher auf die einzelnen Properties eingegangen, da die Beschreibung in der Originaldokumentation bestens aufgelistet ist.

Es können noch diverse andere Fenster auftauchen, die meistens vom Property-Fenster aus geöffnet werden. Wenn man z.B. die Hintergrundfarbe einer Form verändern möchte, so muß man nicht die RGB-Kombination wissen, sondern kann in einem zusätzlichem Fenster aus einer Farbtafel auswählen.

Hier steht Ihnen Sichern oder Sichern als... zur Verfügung. Dies funktioniert wie gewohnt.

Es gibt noch zusätzlich einen Punkt, der „Sichern als Klasse" heißt. Hier können Sie selbst VCX´e erstellen. Die in der Maske gemachten Definitionen können hier in wiederverwendbare Objekte verwandelt werden, deren Aussehen und Funktion in einer anderen Maske verwendet (vererbt) werden können.

Nebenbei noch ein Tip:

Normalerweise wird ein, in einer Form eingegebener Code, beim Abspeichern automatisch compiliert. Wenn jedoch SCX-Dateien per Hand geändert werden, so muß mit COMPILE FORM der Code in den Forms neu übersetzt werden. Da VCX´en den selben Aufbau wie SCX´en haben, ist das COMPILE FORM auch auf VCX´en anzuwenden.

2. Eigenschaften und Methoden

Im ersten Teil haben wir kennengelernt, daß eine Vielzahl an Objekten gibt, die man in einem Formular plazieren kann.

Sie haben auch gehört, daß jedes Objekt Eigenschaften und Methoden (Prozeduren oder Events) beinhalten kann.

Als Eigenschaft kann z.B. die Position in der Form sein, oder dessen Größe und Farbe.

Auch haben spezielle Objekte Ihre speziellen Eigenschaften.

Eine besondere Eigenschaft des Timerobjektes ist z.B. der Intervall, der in Millisekunden angegeben wird. Wird diesem Property ein Wert ungleich 0 angegeben so wird nach Ablauf der eingegeben Zeit die Methode TimerEvent gestartet. Bei dieser Methode handelt es sich um ein normales FoxPro-Programm welches beliebige Aktionen ausführen kann.

z.B.: kann es die Position eines anderen Objektes verändern usw.

Im Gegensatz zu den Properties handelt es sich bei den Methoden um Programme, welche gestartet „gefeuert" werden, wenn eine bestimmte Bedingung eintritt. Eine solche Bedingung kann z.B. eine Nachricht vom Betriebssystem sein, daß die Maus über ein Objekt bewegt wurde, oder ob auf das Objekt geklickt wurde. In diesem Falle spricht man von einem Event.

Andererseits kann eine solche Methode auch programmatisch aufgerufen werden. Es handelt sich ja dabei um ein normales Programm welches gleich einer Prozedur gestartet wird.

Als Beispiel soll hier der DRAG-Event angeführt werden, den Sie selbst starten können, wenn in eine Textbox geklickt wird. Nur so schaffen Sie es, eine Textbox auch wirklich an andere Stellen zu schieben.

Meistens kommt man mit den eingebauten Properties und Methoden aus, um einer Maske Leben einzuhauchen. Aber wenn es darum geht spezielle Code unterzubringen, oder Werte in der Maske abzuspeichern, so muß man sich selbst diese definieren.

Ein spezieller Tip nebenbei:

Wenn Sie eine Variable brauchen, die von mehreren Methoden aus benötigt wird, so müssen Sie ein Property in der Form anlegen, da alle Variablen automatisch Privat deklariert sind, sobald diese in einer Methode verwendet werden. Dieses Property sprechen Sie nun über THISFORM.variable an und kann überall verwendet werden. Dazu gibt es unter dem Menüpunkt FORMS einen Punkt um neue Properties und Methoden anzulegen.

Jedes hier angelegte Property erscheint im Eigenschaftenfenster unter „Andere" am Ende der Liste. Wie normale Variablen werden auch Properties zuerst einmal mit .F. vorbelegt. Wenn Sie einen anderen Anfangswert haben möchten können Sie diesen sofort eintragen oder z.B.: im INIT-Event neu anlegen. Auch Arrays können eingetragen werden. Um dies zu bewerkstelligen müssen Sie in Klammern die Dimensionen andeuten. Also meinarray(1) für eindimensional meinarray(1,1) für zweidimensional. Voreinstellen können Sie diese Arrays nur durch Zuweisung im INIT-Event.

3. Objekte und Daten

Eine Formular macht nur dann ordentlich Sinn, wenn damit Daten behandelt werden. Visual FoxPro 3.0 gibt uns nun Werkzeuge in die Hand, die Datenbearbeitung mit einem Formular zum Kinderspiel machen.

Speziell für die Datenbearbeitung stehen uns verschiedene Properties und Methoden zur Verfügung, die automatisch bei einem Objekt vorhanden sind. Außerdem haben wir die Möglichkeit Tabellen und Ansichten aus Datenbankcontainern der Maske zuzuordnen.

Sobald man ein Formular geöffnet hat, kann man unter dem Menüpunkt „Ansicht", die Datenumgebung öffnen.

In dem nun erscheinenden Fenster kann man beliebige für die Maske notwendige Tabellen und/oder Ansichten abspeichern. Wie fast überall in VFP3.0 ist die rechte Maustaste hier sehr behilflich. Man kann zwar auch über das Menü oder die ebenfalls erscheinende Toolbar eine Tabelle zufügen, jedoch mit der rechten Maustaste geht es am schnellsten. Sobald man eine Tabelle dem Formular zugefügt hat, kann man entweder ein Feld oder die gesamte Tabelle auf das Formular ziehen.

Es wird dann automatisch ein dementsprechendes Element im Formular angelegt. Wird die gesamte Tabelle hinübergezogen, so wird automatisch ein Gridobjekt erzeugt.

Diese Art des Feldanlegens ist die einfachste Art und Weise und erspart einem die Zuweisung der Properties. Allerdings hat es den Nachteil, daß die in VFP3.0 fest eingebauten „Basisklassen" verwendet werden, was ein nachträgliches Ändern schwierig macht.

Unter Visual FoxPro hat man die Möglichkeit, jede Maske mehrmals zu öffnen. Die zugeordneten Daten, bzw. die Tabellen und Ansichten müssen natürlich geöffnet werden um darauf zugreifen zu können. Wenn nun die Tabellen nur einmal geöffnet werden würden, dann würde sich der Satzzeiger jedesmal verändern, wenn man in einer anderen Maske einen anderen Datensatz in der selben Tabelle ansprechen würde. Um dies zu vermeiden hat man die Möglichkeit sogenannte „Private Sessions" zu definieren.

Hier werden die einzelnen Tabellen extra verwaltet und im Speicher verwaltet. Sobald man nun in seiner eigenen Privaten Datenumgebung den Satzzeiger verändert, so wird ein parallel dazu geöffnetes Formular nicht beeinflußt.

Dieses Verhalten kann man einstellen, indem man das Property „Datasession" von 1 (Default Datasession) auf 2 (Private Datasession) stellt.

Hier gleich noch ein nützlicher Tip: Private Datasessions haben die Eigenheit alle SET-Einstellungen auf den amerikanischen Standard zurückzusetzen. Deshalb muß man die notwendigen Einstellungen im LOAD-EVENT der Maske erneut setzen.

Die Datenumgebung ist dem gesamten Formular zugeordnet und in der Form gibt es nun ein spezielles Property, welches angibt, wie VFP3.0 sich beim Datenbearbeiten verhalten soll.

Dieses Property heißt „Buffermode" und kann die Zustände 0 none (default) 1 Pessimitic und 2 Optimistic annehmen.

bedeutet, daß keinerlei Netzwerksperren angewendet werden.

bedeutet, daß der Datensatz gesperrt wird, sobald auch nur eins der Felder bearbeitet wird. Es ist wichtig zu wissen, daß die Sperre erst dann in Kraft tritt, wenn ein Feld bearbeitet wird und nicht, wenn der Datensatz gelesen wird. Dieses Verhalten ist das „Alte" aus FPW2.6. Sie werden beim Umstieg auf VFP3.0 mit diesem Sperrverhalten die wenigsten Probleme haben.

bedeutet, daß erst beim Verlassen oder expliziten Speichern mit TABLEUPDATE() der Datensatz gesperrt wird und erst dann die Daten weggeschrieben werden.

Neben dem Sperrverhalten kann nun auch Datenpufferung eingestellt werden. Dies wird durch das Property „Buffermode Override" aus der Datenumgebung heraus eingestellt.

Zur Verfügung stehen folgende Einstellungen

Dies ist defaultmäßig eingestellt und bedeutet, daß die Einstellungen der Form übernommen werden.

Dies bedeutet, daß der einzelne Datensatz sofort gesperrt wird und die Daten in die Originaltabelle geschrieben werden, sobald der Datensatz gewechselt wird, oder TABLEUPDATE() durchgeführt wird. Sollte gewünscht werden, daß die Daten nicht weggeschrieben werden, so kann mit TABLEREVERT() der originale Zustand wiederhergestellt werden.

Hier wird ebenfalls nur ein Datensatz gesperrt, jedoch erst wenn der Datensatz verlassen wird, oder TABLEUPDATE() durchgeführt wird.

Diese Einstellung funktioniert genauso wie das pessimistische Row Buffering, jedoch wird hier jeder angesprochene Datensatz gepuffert. Achten Sie darauf, daß in diesem Falle SET MULTILOCKS auf ON stehen muß.

Diese letzte Einstellung bezieht sich ebenfalls auf die gesamte Tabelle, verhält sich ansonsten genauso, wie das optimistische Row Buffering.

4. Visual Custom eXtensions

Die VCX´e sind die VFP3.0 eigenen Bausteine, ähnlich den OCX´en oder VBX´en.

Diese Dateien können mehrere Visuelle Klassen beinhalten. Also wie der Name bereits verrät, sichtbare Objekte mit Programmcode dahinter. Selbstverständlich können diese Objekte vererbt werden und fügen sich nahtlos in ein Formular ein.

Die VCX´e können aus allen Visuellen Basisklassen bestehen und jede beliebige Form annehmen. Eine einzige Klasse könnte ein ganzes Programm beinhalten. Mit VFP3.0 haben Sie bereits ein paar Demonstrationsklassen mitgeliefert bekommen, welche Sie frei verwenden können. (Siehe im Verzeichnis samples\controls )

Es ist möglich mit dem Formulardesigner sich eigene VCX´e zu erstellen, indem man im Hauptmenü „Als Klasse speichern" wählt.

Sobald man diesem Menüpunkt gewählt hat, kann man auswählen, ob man die gesamte Maske oder nur die darin befindlichen Objekte als Klasse speichern möchte. Wählt man „Aktuelles Formular" so wird beim Wiederhereinholen der Klasse das aktuelle Formular überschrieben.

Wählt man „Ausgewählte Steuerelemente", so werden beim wiederhereinholen der Klasse diese Elemente in das aktuelle Formular eingefügt.

Beim Abspeichern muß man sich für einen Namen entscheiden, unter dem die Elemente in einer VCX-Datei gespeichert werden. Es können so beliebig viele Klassen in einer VCX untergebracht werden.

Letztendlich muß noch die physikalische VCX-Datei benannt werden in der die Klasse gespeichert wird.

Übernommen wird jedes gewählte Objekt mit dessen Properties und Methoden.

In der Form Control Toolbar steht uns folgendes Symbol zur Verfügung

Klassen anzeigen

Das dahinter verborgene Menü ermöglicht uns neue Klassen hinzuzufügen, die Standardklassen anzuzeigen oder OLE-Steuerobjekte einzufügen.

Sobald man eine VCX-Datei hinzufügt, werden die darin enthaltenen Klassen als kleine Icons in der Form Control Toolbar angezeigt.

Die neuen Klassen kann man nun genauso wie die Basisklassen frei auf der Form anordnen. Die Properties werden dabei voll übernommen.

Die Methoden sind auf den ersten Blick nicht sichtbar, werden jedoch angewendet, wenn man diese nicht mit eigenem Code überschreibt. Eine Übernahme der Methoden erzwingt man mit folgender Schreibweise:

wichtig sind dabei die zwei Doppelpunkte, die angeben, daß der Code aus der vererbten Klassen eingefügt werden soll.

5. OLE-OBJEKTE einbinden

Eine der wichtigsten Neuerungen stellt die Verwendung von OLE2 Objekten dar. Darunter versteht man fremde Programme, die nahtlos in die eigene Applikation eingefügt werden, wobei man die Umgebung des eigenen Programmes nicht verläßt. OLE2 Objekte fügen sich nahtlos in bestehende Formulare ein und deren Funktionalität kann frei im eigenen Programm verwendet werden.

Am Beispiel eines eingebundenen Winword´s sieht man, daß beim „Betreten" des Objektes die Menüs und TOOLBARS gegen die des WinWord´s ausgetauscht werden und man sich sozusagen im WinWord befindet, ohne FoxPro verlassen zu haben.

ein OLE Objekt wird durch

OLE-Container-Steuerelement

angelegt. Ein einfaches Ziehen eines Rahmens definiert die Position am Bildschirm, bzw. in Ihrem Formular. Sobald man den Platz durch ziehen eines Rahmens definiert hat, kommt man in ein Dialogfenster „Einfügen Objekte". Hier hat man nun drei Möglichkeiten auszuwählen.

Aus einer Liste können Sie die in Ihrem System eingetragenen OLE-Server, sprich Programme die OLE2 fähig sind, auswählen. Als OLE2 Server gilt z.B. Paint oder WinWord, Excel usw. Wählen Sie eines dieser Programme aus, so wird es im Hintergrund gestartet und erscheint bei jedem Klick darauf, als Fenster in Ihrer Maske.

Hier haben Sie die Möglichkeit, eine Datei anzugeben deren Programm automatisch aufgerufen wird, welches es erzeugt hat. Eine XLS-Datei wird dann automatisch von Excel bearbeitet.

Hier können Sie eines der neuen OCX´e einbinden. Zur Zeit stehen nur wenige solcher Programmteile zur Verfügung, aber viele Entwickler haben bereits angekündigt in absehbarer Zeit OCX´e zu entwickeln und anzubieten. Unter anderem wird es dann Textverarbeitungen usw. geben, die Sie hiermit auf einfachste Art und Weise einbinden können.

Zum sogenannten Ausprobieren wurde VFP3.0 z.B. das Outline-OCX mitgegeben. Dieses Objekt zeigt eine Baumstruktur an, die Sie als Programmierer selbst gestalten können.

Holen Sie sich dieses Objekt einmal in eine Ihrer Maske und Sie erkennen sofort eine Darstellung, wie sie uns vom Dateimanager her bekannt ist. Mit diversen Eigenschaften und Methoden können Sie nun von außen auf dieses Objekt einwirken.

So richtig Sinn, macht ein WinWord in Ihrer Maske, wenn Sie Ihr WinWord-Dokument aus einer Datenbank beziehen können. Zu diesem Zweck gibt es

gebundene OLE Steuerelemente.

Dieses Objekt verhält sich im Grunde genauso wie ein normales OLE2 Objekt. Die Daten die es benötigt bekommt es jedoch direkt von FoxPro.

Das General-Feld in einer Datenbank können Sie verwenden um einerseits WinWord-Dokumente, andererseits Paintbrush-Bilder zu bearbeiten. Die nette Eigenheit dieses Objektes ist die Tatsache, daß jeweils das benötigte Programm geladen wird, wenn es sich um unterschiedliche OLE-Datentypen handelt. Es ist auch möglich OLE1 Objekte zu verwalten, allerdings können dann die Programme nicht mehr in Ihrer Maske erscheinen, sondern werden als einzelne selbständige Programm aufgerufen.

6. Eigene TOOLBARS erzeugen

Als eine der neuen „Schönheiten" kann man die TOOLBARS bezeichnen. Es handelt sich dabei eigentlich um normale Fenster, die verschiedene Knöpfe oder Symbole beherbergen. VFP selbst weiß was es zu tun hat, wenn man eine solche Toolbar mit der Maus verschiebt und z.B. am Bildschirmrand „andockt".

Das Toolbar-Objekt selbst ist ein Containerobjekt und kann mittels CREATE class angelegt werden. Ein einzelnes „CREATE class" öffnet ein Dialogfenster, in dem Sie angeben können, wie die Klasse heißt, von welcher Basisklasse sie abstammt und in welcher VCX sie gespeichert werden soll.

Als Basisklasse verwenden Sie hier natürlich „Toolbar".

Nun bekommen Sie eine kleine Toolbar gezeigt, die zuerst noch leer ist. In diese Toolbar können Sie nun Objekte plazieren, wie Sie es für notwendig erhalten. Die Objekte haben nun wieder Eigenschaften und Methoden, die Sie nach Ihren Wünschen definieren können.

Sobald Sie die Klasse abspeichern, können Sie sich die Toolbar nun frei verwenden.

Zuerst müssen Sie die Klassen dem System bekannt geben. Am einfachsten geschieht das durch den Befehl:

Nun müssen Sie das Objekt Toolbar erzeugen. In der VCX steht ja nur die Beschreibung der Toolbar. Dies geschieht durch:

x ist dabei eine beliebige Variable, unter deren Name wir unser Objekt wiederfinden können.

Klassenname ist nun der Name der Toolbar unter der sie in der VCX-Datei gespeichert wurde.

Mit x.show erscheint die Toolbar auf dem Bildschirm und kann ganz normal verwendet werden.

x.release läßt die Toolbar wieder verschwinden und entfernt sie auch noch gleichzeitig aus dem Speicher.

7. Das Gridobjekt

Das Gridobjekt ist eines der mächtigsten und auch kompliziertesten Objekte, die VFP3.0 zu bieten hat.

Grundsätzlich handelt es sich um ein Containerobjekt welches wiederum andere Objekte in sich beherbergen kann. Standardmäßig ist ein Header-Objekt, also die Überschrift, und ein Textobjekt eingebunden.

Diese Zusammenstellung entspricht einem normalen Browse-Window wie wir es aus der 2.x Zeit her kennen.

Das Gridobjekt ist jedoch weitaus mehr. Sie können nahezu alles damit machen solange es sich dabei auf eine Tabelle oder Cursor handelt.

Die einzelnen Eigenschaften aufzuzählen und zu beschreiben würde den Rahmen dieses Dokumentes sprengen, aber einige Spezialitäten möchte ich hier doch aufführen.

Natürlich gibt es hier wieder die Möglichkeit durch die Angabe einer „Recordsource" anzugeben, woher die Daten stammen, die angezeigt werden sollen. Weiters haben Sie die Möglichkeit durch die Eigenschaft „Linkmaster" anzugeben, wie die Tabelle in Relation zu einer anderen steht. Auch kann der Index bestimmt werden, nachdem die Tabelle gereiht werden soll. Dies geschieht durch die Eigenschaft „Childorder".

Die Anzahl der Spalten wird durch „ColumnCount" angegeben. Wenn diese -1 darstellt, so wird automatisch die volle Tabelle hereingeholt. Sobald Sie die Zahl erhöhen, so wird das Gridobjekt sozusagen erweitert und es stehen pro Spalte ein Headerobjekt und ein Textobjekt zur Verfügung.

Zur Veranschaulichung:

Anstelle eines Textobjektes kann nun jedes andere Element eingesetzt werden, solange es fähig ist, in einem Containerobjekt Platz zu nehmen. (Ausnahmen sind hier Form und Formset)

Zum Beispiel kann hier ein Commandbutton stehen, der wenn er gedrückt wird z.B. eine Telefonnummer wählt.

9. Die Basisklassen

Um von Klassen sprechen zu können, muß ich zuerst einmal weiter ausholen und Objekte, an sich, erklären.

Unter VFP3.0 ist alles ein Objekt und jedes Objekt liegt in einem Container. Selbst VFP3.0 ist ein Objekt und liegt in Windows eingepackt im Speicher. Genaugenommen wird jedes VFP-Object selbst von VFP gemalt. Ausnahmen sind hier die Windows selbst, die vom „echten" Windows gezeichnet werden.

VFP3.0 selbst wird über die Systemvariable _screen angesprochen. Vermeiden Sie bei DEFINE WINDOW Anweisungen den Namen SCREEN oder ähnliches. Es könnte intern zu Konflikten kommen. Wenn Sie nun ein Formular oder eine Toolbox auf den Bildschirm bringen, so wird in VFP3.0 dazu ein Speicherbereich reserviert und mit einem Namen versehen, damit man diesen Speicherbereich jederzeit beeinflussen kann.

Ein Formular liegt dann sozusagen in dem Vaterobjekt „_screen" eingebettet. In VFP3.0 wurden mehrere Platzhalter eingeführt, die indirekt auf andere Objekte zeigen. „parent" ist z.B. ein Zeiger auf das in der Hierarchie darüberliegende Objekt. Liegt ein Formular am Bildschirm, so ist _screen sein „parent".

Auch kann das aktuelle Objekt angesprochen werden, ohne dessen Name selbst zu kennen. (Dies ist notwendig, wenn Klassen ihren Namen ändern)

Um auf ein FORMSET (ein Zusammenschluß mehrerer Formulare) zugreifen zu können, so können Sie entweder dessen Name verwenden, oder eben einen Platzhalter mit der Bezeichnung THISFORMSET.

Eine Form wird mit THISFORM referenziert und das einzelne Objekt ist durch THIS zu erreichen.

Beispiel: Auf dem Bildschirm liegt ein Formular mit einem einzelnen Commandbutton. Wenn Sie nun die Schriftart des Commandbuttons verändern möchten, dann haben Sie die Möglichkeit dies mit THIS.FontName=„Curier New" zu erledigen. In diesem Falle wird die Änderung auch sofort ausgeführt. Es gibt auch noch andere Eigenschaften, wo ein Refresh der Maske notwendig wird, damit Daten am Schirm auch angezeigt werden.

Wenn Sie nun in der Click Methode des Commandbuttons, THISFORM.Release hinterlegen, so wird das Formular released, also aus dem Speicher entfernt. Dies hat natürlich auch die Folge, daß das Fenster vom Schirm verschwindet und das Programm beendet wird.

Visual FoxPro 3.0 ist nun mit den wichtigsten Klassen bereits ausgestattet, damit man ordentliche Windowsprogramme erzeugen kann. Diese Klassen nennt man Basisklassen, da von diesen alle VFP-Klassen abgeleitet werden.

Man muß bei den einzelnen Basisklassen aber noch unterscheiden, ob es sich dabei um ein Containerobjekt handelt oder ob es z.B. ein Objekt ist, welches nur in einem bestimmten Containerobjekt liegen kann. (Beispiel: Header kann nur in einem Grid vorkommen)

Hier eine Aufstellung der Klassen:
Container kann beinhalten
FormSet Form
Form PageFrame und jede andere Klasse darunter
PageFrame Page
Page Jede Klasse darunter
CommandButtonGroup CommandButton
OptionButtonGroup OptionButton
Grid Column
Column Header, CheckBox, ComboBox, CommandButton, EditBox, ListBox, OptionBox, Spinner, TextBox, Grid
Selbstdefinierte Objekte Alle Klassen

 

Da eine komplette Aufzählung aller Möglichkeiten, Eigenschaften und Methoden alle Grenzen sprengen würde, so darf ich Sie auf die Hilfedatei verweisen, in der Sie unter „The Visual FoxPro Base Classes" eine vollständige Auflistung erhalten.

10. Die Formular Optionen

Im Menüpunkt Extras können die Optionen angezeigt werden. Speziell für die Formulare und den Formdesigner gibt es hier eine eigene Seite, bei der verschiedene Standardeinstellungen gemacht werden können.

Unter anderem kann man für das FormSet und die einzelne Form eine sogenannte Klassenvorlage (im Englischen Templates) bestimmen.

Es handelt sich dabei um normale VCX´e, deren Inhalt beim Neuanlegen eines Formulars hereingeholt wird.

Hier können Sie z.B. bereits die Hintergrundfarbe festlegen usw. Ein besonderer Vorteil ist dabei, daß Sie beim Verändern der Klassenvorlage automatisch alle damit erstellten Formulare ebenfalls verändern, ohne irgend etwas neu generieren oder kompilieren zu müssen.

11. Error loading Form. .... Record number ...

Es wird Ihnen garantiert einmal passieren, daß Sie diese Meldung am Schirm sehen und eventuell schaffen Sie es nicht mehr die Form mit MODI FORM formname aufzumachen. Jetzt heißt es, „nicht verzagen". Wie immer und überall liegen uns die Metadaten der Form zu Füßen und wir müssen diese nur in die Hand nehmen und überarbeiten. Im Falle einer Form ist dies eben die SCX-Datei. Ein einfaches USE meineform.SCX und dann ein BROWSE zeigt uns den Inhalt der Datei. Passen Sie jedoch auf, was Sie machen. Ein „ungeschultes" Eingreifen hat schon so manche Form für immer verschwinden lassen. Auf alle Fälle ist bei der oben genannten Fehlermeldung die Datensatznummer dieser SCX gemeint. Meistens „happerts" beim Datenevironment. Leider läßt sich hier nicht genau ermitteln, welche Datei gemeint ist. Also hilft nur noch suchen. Aber auf alle Fälle sollten Sie sich folgende Felder genauer ansehen.

Wenn Sie die SCX händisch ändern, dann sollten Sie diese mit dem COMPILE FORM Befehl neu compilieren lassen. Ansonsten kann es passieren, daß gewisse Funktionen nicht zur Verfügung stehen.