[ 1 ] [ 2 ]
Der Database-Designer sollte eigentlich die Datenmodellierungs-Zentrale von VFP sein, doch leider wird er dieser Anforderung nur sehr wenig gerecht. Eine nicht allzu übersichtliche Darstellung und mangelnde Datenbank-Design-Fähigkeiten fallen deutlich hinter den Möglichkeiten zurück, die die VFP-Datenbank-Engine bietet. Die beste Empfehlung an dieser Stelle ist der Einsatz des Datenbank-Case-Tools "xCase" (siehe Vendor-Room), welche eine komplette Entity-Relationship-Modellierung erlaubt und und keine redundanten Definitionsschritte erfordert.
Die wichtigste Neuerung im Datenbankdesigner gegenüber VFP 3.0 ist die Multuser-Fähigkeit. Ein Datenbank-Container kann jetzt SHARED geöffnet und damit von mehreren Entwicklern zugleich bearbeitet werden (siehe auch Session E-TEAM). Allerdings kann ein konkretes Objekt (Tabelle, View, Connection) immer nur von einem Entwickler verändert werden. Außerdem können einige Eigenschaften weiterhin nur geändert werden, wenn der DBC exklusiv geöffnet ist (z.B. der RI-Code).
Zur Verbesserung des Überblicks im Datenbank-Designer sind einige Funktionen zum "Ordnung machen" auf der Designer-Arbeitsfläche eingebaut worden:
Außerdem wurden die einzelnen Objekte (Tabellen, Views usw.) mit spezifischen Icons versehen, die die Unterscheidung der Objekt-Arten erleichtert.
Auf die Veränderungen der anderen zum Datenbankdesigner gehörenden Tools (Tabellen-, View- und Connection-Designer) wird in separaten Punkten eingegangen.
Eine äußerst wichtige Neuerung betrifft die Arbeit mit den Validation Rules (siehe Abschnitt "Table-Designer").
Für detaillierte Informationen zum Database-Designer sei auf die Session D-DATA verwiesen.
| Ein vergleichbares Tool hat in FoxPro für Windows 2.6 nicht existiert. |
Der Table-Designer dient dem Erstellen und Verändern von Tabellen (DBF-Dateien). Visual FoxPro 5.0 unterscheidet "free tables" (DBF-Dateien der herkömmlichen Manier) und "database related tables" (DBF-Dateien, die zu einem Datenbank-Container gehören). Die meisten neuen Features der VFP-Datenbank-Engine stehen nur für "database related tables" zur Verfügung (siehe auch Punkt "Die Datenbank-Engine" des vorliegenden Dokuments).
Als Datentypen stehen zur Verfügung:
| >Field type | >Description | >Size | >Range |
|---|---|---|---|
| Character | Any text | 1 byte per character to 254 | Any characters |
| Currency | Monetary amounts | 8 bytes | – 922337203685477.5808 to 922337203685477.5807 |
| Date | Chronological data consisting of month, year, and day | 8 bytes | 01/01/100 to 12/31/9999 |
| DateTime | Chronological data consisting of month, year, day, and time | 8 bytes | 01/01/100 to 12/31/9999, plus 00:00:00 a.m. to 11:59:59 p.m. |
| Logical | Boolean value of true or false | 1 byte | True (.T.) or F |
| Numeric | Integers or fractions | 8 bytes in memory;
1 to 20 bytes in table |
– .9999999999E+19 to .9999999999E+20 |
| Double | A double-precision floating-point number | 8 bytes | +/–4.94065645841247E-324 to +/–8.9884656743115E307 |
| Float | Same as Numeric | 8 bytes in memory;
1 to 20 bytes in table |
– .9999999999E+19 to .9999999999E+20 |
| General | Reference to an OLE object | 4 bytes in table | Limited by available memory |
| Integer | Integer values | 4 bytes | –2147483647 to 2147483646 |
| Memo | Reference to a block of data | 4 bytes in table | Limited by available memory |
| Character (Binary) | Any character data you want to maintain without change across code pages | 1 byte per character to 254 | Any characters |
| Memo (Binary) | Any memo field data you want to maintain without change across code pages | 4 bytes in table | Limited by available memory |
Neben den eigentlichen Feldeigenschaften wie Name, Datentyp und Feldlänge können eine ganze Reihe weiterer Eigenschaften bestimmt werden:
| >Bezeichnung | >Bemerkungen |
|---|---|
| Caption | Klartextbezeichnung des Feldes (darf auch Leerzeichen enthalten): findet als Spaltenüberschrift im BROWSE-Fenster Verwendung kann über GETPROP() programmatisch abgefragt und weiterverarbeitet werden |
| Format,
InputMask |
Format-Einstellungen (Nachkommastellen usw., bei Drag&Drop-Operationen automatisch übernehmbar) |
| DisplayClass,
DisplayLibrary |
Klasse, die beim Drag&Drop automatisch für die Darstellung des Controls verwendet werden soll |
| Field validation rule | logischer Ausdruck oder userdefined function (UDF) zur Validierung des betreffenden Feldes |
| Field validation message | Zeichenketten-Ausdruck oder userdefined function (UDF) zur Erzeugung des anzuzeigenden Fehlertextes, wenn die Validierung verletzt wird |
| Default value | Ausdruck oder userdefined function (UDF) zur Ermittlung der Standardwertes des betreffenden Feldes (wird z.B. bei APPEND BLANK benutzt) |
In Visual FoxPro existieren vier Arten von Indizies:
| >Index-Typ | >Bemerkungen |
|---|---|
| regular | normaler Index (wie bisher unter FoxPro für Windows 2.6 üblich) |
| unique | dieser Indextyp existiert auch schon in FoxPro für Windows, hatte aber schon damals einen heftigen Bug (keine automastische Erneuerung beim Löschen von Datensätzen) und sollte deshalb heftig gemieden werden |
| candidate | dieser Index ist ein eindeutiger Index, dessen Eindeutigkeit von VFP überwacht wird |
| primary | analog dem candidate-Index (genau einer der candidate-Indizies einer Tabelle kann zu Organisationszwecken zum primary-Index erklärt werden) |
Die Länge eines Index-Schlüssels ist auf maximal 240 Zeichen begrenzt (INDEX ON LEFT( xyz, 255 ) ist also nicht zulässig). Die Länge des Index-Schlüssel halbiert sich auf 120, wenn mit DoubleByte-Collate-Sequenzen gearbeitet wird.
Zusätzlich zu den feldbezogenen Eigenschaften und den Indizies existieren einige wichtige datensatz-bezogene Eigenschaften:
| >Bezeichnung | >Bemerkungen |
|---|---|
| Record validation rule | logischer Ausdruck oder userdefined function (UDF) zur Validierung des betreffenden Datensatzes |
| Record validation message | Zeichenketten-Ausdruck oder userdefined function (UDF) zur Erzeugung des anzuzeigenden Fehlertextes, wenn die Validierung verletzt wird |
| Insert trigger | userdefined function (UDF), die automatisch immer beim Anlegen eines Datensatzes abgearbeitet wird (unabhängig davon, auf welchem Weg der Datensatz entstanden ist) |
| Update trigger | userdefined function (UDF), die automatisch immer beim Ändern eines Datensatzes abgearbeitet wird |
| Delete trigger | userdefined function (UDF), die automatisch immer beim Löschen eines Datensatzes abgearbeitet wird |
In die Trigger trägt auch Visual FoxPro auf Wunsch Aufrufe von Funktionen ein, die die "refential integrity" einer Datenbank überwachen und z.B. verhindern können, daß ein Kunde gelöscht wird, zu dem noch offene Rechnungen existieren. Die hierzu notwendigen Programm-Quelltexte werden entweder durch den Referential-Integrity-Builder von nVFP oder z.B. durch xCase (siehe oben) erzeugt und in den sogenannten "stored procedures" abgelegt.
Die "stored procedures" sind direkt in der Datenbank gespeicherter FoxPro-Quelltext, der in jeder beliebigen Programmsituation zur Verfügung steht (unabhängig von gesetzten Prozedur- und Klassenbibliotheks-Dateien).
Neu in Visual FoxPro 5.0 ist das sogenannte "field mapping". Diese Funktionalität wird über die Page "Field mapping" unter "Tools \ Options" gesteuert. Dort kann man generelle Festlegungen für solche Drag&Drop-Operationen treffen:
Legt man im Table-Designer für ein Datenbankfeld explizit eine selbstdefinierte Klasse fest, so wird dadurch die allgemeinere Einstellung aus "Tools \ Options" überschrieben.
Außerdem wird bei den Drag&Drop-Operationen auch die unterschiedliche Zeichenanzahl der Datenbankfelder beachtet und in unterschiedliche Breiten der jeweiligen Controls umgesetzt.
Der optischen Umgestaltung des Tabledesigners ist leider die eigentlich wichtige Anzeige zum Opfer gefallen, welches Datenbankfeld gerade aktiv ist. Deshalb ist zu noch größerer Aufmerksamkeit zu raten bei der Vergabe von Feld-Eigenschaften, damit diese dann auch dem richtigen Feld zugeordnet sind.
Ein wesentliche Neuerung ist die Tatsache, daß in den Validations Rules jetzt auch Veränderungen an den zu prüfenden Daten vorgenommen werden können!
In der Satz-Validierung der Customer-Tabelle kann z.B. die Zeile "REPLACE Title WITH UPPER(Title)" stehen, welche dazu führt, daß im Feld "Title" unabhängig von der Eingabe oder von anderen REPLACE-Befehlen immer nur Großbuchstaben gespeichert werden. Plaziert man den Befehl "REPLACE Title WITH UPPER(Title)" allerdings in der Validation-Rule des Feldes "Title", dann muß man sich mit zusätzlichen Maßnahmen gegen die dabei auftretende Rekursion absichern.
Zu beachten ist allerdings, daß dieses Verhalten nur für Validation Rules gilt, nicht für Trigger!
| Alles in allem ist der Table-Designer eine folgerichtige Weiterentwicklung des bekannten MODIFY-STRUCTURE-Dialogs. |
| Zur Verarbeitung von FPW2.6-DBF-Dateien ist folgendes zu beachten:
Diese Dateien können ohne jedwede Konvertierung von Visual FoxPro gelesen und auch geschrieben werden, ohne daß sie dadurch für FoxPro für Windows 2.6 unbenutzbar werden. FPW2.6-DBF-Dateien werden dann automatisch und ohne Warnung unbenutzbar: wenn eine solche Tabelle in einen Datenbank-Container integriert wird wenn Strukturänderungen vorgenommen werden, die auf Möglichkeiten zurückgreifen, die in FoxPro für Windows noch nicht vorhanden waren (neue Daten- oder Index-Typen, Nullwertunterstützung usw.) |
Die View-Designer in VFP 5.0 bieten eine Reihe von Erweiterungen, die schon in anderen Zusammenhängen erwähnt wurden:
Desweiteren wurde der VIEW-Typ "OFFLINE-View" eingeführt, der ein zeitweiliges von der eigentlichen Datenquelle unabhängiges Arbeiten erlaubt (siehe Sessions der Sektion DATA).
Wie schon VFP 3.0 unterstützt auch VFP 5.0 das ODBC-Level 3, auch für VFP 5.0 - Datenbanken existiert ein ODBC-Treiber.
| Der View-Designer von Visual FoxPro 5.0 hat große Ähnlichkeit mit dem Query-Designer von FoxPro für Windows 2.6. Im Gegensatz zu diesem wird aber in VFP5.0 kein Quelltext generiert, sondern in der Datenbank ein updatable View angelegt, der wie eine DBF-Datei mit USE geöffnet und mit (fast) allen für Tabellen verfügbaren Befehlen verarbeitet werden kann (also auch mit REPLACE, INSERT, DELETE, APPEND usw.!). |
Der Programm-Editor von Visual FoxPro 5.0 hat eine ganze Menge an Funktionalität hinzugewonnen, die sich zum Teil auch bei verwandten Fenstern (Command Window, Methoden-Editor) wiederfindet.
Die auffälligste Neuerung ist das Syntax Coloring, welches automatisch bestimmte Quelltext-Teile in verschiedenen Farben darstellt (die Einstellungen dazu kann man unter "Tools / Options" auf der Page "Syntax Coloring" vornehmen).
Alle anderen Neuerungen beziehen sich auf das Kontext-Menü, welches jetzt auch in Editorfenstern zur Verfügung steht:
| Ingesamt ist der Editor durch diese Erweiterungen erheblich aufgewertet worden, sodaß kaum noch die Notwendigkeit besteht, einen externen Editor einzusetzen. |
In diesem Abschnitt sollen sowohl die Neuerungen im Formdesigner als auch die neuen Möglichkeiten der programmtechnischen Arbeit mit Forms kurz erläutert werden.
Die wichtigen Neuerungen im Formdesigner betreffen alle die Verbesserung der Handhabung dieses Werkzeuges:
| Alles in allem unterscheidet sich der Formdesigner in seiner Grundphilosophie nicht wesentlich von dem Äquivalent aus FoxPro für Windows 2.6. Hinzugekommen sind lediglich die OOP-Spezifika sowie eine Unmenge von Methoden und Properties für die einzelnen Objekte (für den Umgang mit diesen Dingen sei auf die Sessions der Sektionen OOP und SOFT sowie auf die Session D-EINS verwiesen!). |
Im programmatischen Umgang mit Forms ergeben sich drei wesentliche Neuigkeiten:
Mit dem Single Document Interface SDI hat man die Möglichkeit, vom VFP-Desktop unabhängige Fenster zu definieren, die dann als selbständige Desktops agieren können. Die Leistungsfähigkeit solcher SDI-Fenster geht weit über den Effekt des "Desktop"-Property von VFP 3.0 hinaus. SDI-Fenster können andere Fenster beinhalten, können ein eigenes Menü und eigene Toolbars haben.
Daraus ergeben sich folgende neue Möglichkeiten:
Die Programmierung von SDI-Forms ist allerdings nicht ganz ohne Hürden, da man eine genau abgestimmte Einstellung der Properties "ShowWindow", "DeskTop", "MDIForm" und "WindowType" sowie von _SCREEN.Visible benötigt, um die gewünschten Effekte zu erreichen; wie der nachfolgende Ausschnitt aus der README.HLP zeigt:
Creating Modal and Modeless SDI and MDI Forms
To create modal or modeless SDI and MDI forms, you must set three properties; the documentation discusses only two.
The following table illustrates the combination of form properties you set to arrive at different types of forms: modal and modeless forms, as both MDI and SDI windows. In the table, “Traditional” refers to an application like that created in Visual FoxPro 3.0, in which the Visual FoxPro main window serves as the desktop. In an MDI application, the form is a child window of a form called WindMain, which serves as the desktop. An SDI application features a floating form.
| Application Style | Modal form | Modeless form | Desktop |
|---|---|---|---|
| Traditional | ShowWindow = 0
DeskTop = .F. WindowType = 1 |
ShowWindow = 0
DeskTop = .F. WindowType = 0 |
_SCREEN.Visible = .T.
(_SCREEN serves as the desktop) |
| MDI | ShowWindow = 1
DeskTop = .F. WindowType = 1 |
ShowWindow = 1
DeskTop = .F. WindowType = 0 |
_SCREEN.Visible = .F.
WindMain.ShowWindow = 2 WindMain.WindowType = 0 (The custom form WindMain serves as the desktop) |
| SDI (TopLevel) | ShowWindow = 1
DeskTop = .T. WindowType = 1 |
ShowWindow = 2
WindowType = 0 |
_SCREEN.Visible = .F.
(No desktop form; the Windows desktop is the dekstop for the application) |
Auch der Umgang mit Menüs in SDI-Forms ist etwas trickreich, da der Menügenerator für solche Menüs z.B. die Option "Anfügen" bzw. "Einfügen" urspünglich nicht unterstützte (mittlerweile gibt es einen aktuelleren GENMENU.PRG).
ShortCut-Menüs sind eine neue Option im Menüdesigner. Damit erstellt man Popups, die über den RightClick-Event als Kontextmenüs aktivierbar sind (im WIN95 - Look & Feel).
Wichtige neue Properties im Zusammenhang mit der Arbeit mit Forms sind:
Weitere Neuerungen sind der Übersicht "Neue und erweiterte Sprachelemente von Visual FoxPro 5.0" am Ende dieses Artikels bzw. der Begleitdiskette zu entnehmen.
Der Debugger in Visual FoxPro 5.0 ist nicht mehr wiederzuerkennen. Statt des alten DEBUG- bzw. TRACE-Fensters existieren jetzt fünf Fenster, die man entweder als Toolbars innerhalb seiner Applikation oder in einem separaten, von der Applikation unabhängigen Fenster sichtbar machen kann (welches dann auch als eigenständige Task zu erreichen ist):
Außerdem wurden die Möglichkeiten der BreakPoint-Definition wesentlich erweitert (auch im Programmquelltext!). Weiterhin sind EventTracking (erlaubt das Verfolgen und Protokollieren der Abarbeitung von Events) und Coverage-Logging (Protokollierung der Programm-Abarbeitung zur Analyse der Performance eines Programms) hinzugekommen.
Einmal definierte Einstellungen können in sogenannten Debugging Sessions gespeichert und bei Bedarf wieder restauriert werden.
Desweiteren wird innerhalb des Debuggers ein weitreichendes Drag&Drop unterstützt (z.B. vom Trace- zum Watch-Fenster).
Erweiterungen der VFP-Programmiersprache im Zusammenhang mit dem Debugger sind _COVERAGE, ASSERT, CLOSE DEBUG, DEBUG, DEBUGOUT, SET ASSERTS, SET COVERAGE, SET DEBUGOUT, SET EVENTLIST, SET EVENTTRACKING.
Für ausführliche Informationen zu diesem Thema sei auf die Session D-BUG verwiesen.
| Alle hier beschriebenen Neuerungen sind auch für Aufsteiger von FoxPro für Windows 2.6 relevant, da der Debugger aus VFP3.0 immer noch dem von FPW2.6 entsprach! |
Neue Wizards in Visual FoxPro 5.0 sind:
Erweitert oder verbessert wurden folgende Wizards:
[ 1 ] [ 2 ]