Der Wechsel der Versionsnummer vor dem Komma hat Microsoft als Benennung der neuen Version von FoxPro nicht gereicht, auch der Name ändert sich zu Visual FoxPro. Diese klare Abgrenzung zu den Vorgängerversionen ist berechtigt und notwendig, denn Visual FoxPro (im folgenden auch kurz VFP) ist mehr als ein Update. VFP konfrontiert den FoxPro-Entwickler in vielen Bereichen mit völlig neuen Konzepten. Die versprochene Abwärts-Kompatibilität erlaubt es jedoch, bereits bestehende FoxPro 2.6-Projekte in die neue Umgebung zu übernehmen. Dies ist aber nicht 1 zu 1 möglich, sondern es müssen viele Dinge beachtet werden, um die neuen Möglichkeiten nutzen zu können
Eine beliebte Methode, um Programme unter FoxPro 2.6 lesbar zu halten, ist es, Variablen mit mehr als den 10 Zeichen, die zur Unterscheidung notwendig sind, zu benennen. In Visual FoxPro können Variablen- wie auch Konstantennamen bis zu 255 Zeichen lang sein. Hat man in dem Teil des Namens, der für FP 2.6 nicht signifikant ist, einen Tipfehler gemacht, hat dies einen Fehler im nach VFP übernommenen Programm zur Folge.
Der erste Schritt bei der Übernahme von Programmen nach VFP sollte also eine Analyse des alten Projektes sein, um solche Fehler, die sich in VFP - auch wegen der noch neuen Umgebung - nur schwer aufspüren lassen, zu vermeiden.
Die Analyse eines FoxPro 2.6-Projektes kann man mit dem Documenting Wizard aus VFP machen. Dazu sollten zuerst alle Programme des Projektes in FoxPro 2.6 neu generiert werden.
Der Documenting Wizard legt unter anderem eine .DBF mit Einträgen von jedem Auftreten aller Symbole (Variablen, Prozeduren, Aliases) an. Diese Datei heißt FDxRef.DBF.
Die Struktur von FDxRef ist:
| FDxRef.dbf | ||
|---|---|---|
| Feldname | Typ | Inhalt |
| SYMBOL | (C(65)) | Der Name des Symbols. |
| PROCNAME | (C(40)) | Der Name der Prozedur, in der das Symbol gefunden wurde. |
| FLAG | (C(1)) | Eine Kennung, was mit dem Symbol an der Stelle gemacht wird: D: Definition Prozedur F: Dimensionierung Array/ DO ... N: Alias in SQL R: Referenzierung V: Deklaration (PRIVATE...) |
| LINENO | (N(5)) | Zeilennummer, in der das Symbol referenziert wird. |
| SNIPRECNO | (N(5)) | Satznummer des Snippets. (nur für VFP-SCX) |
| SNIPFLD | (C(10)) | Feldname des Snippets (nur für VFP-SCX) |
| SNIPLINENO | (N(5)) | Zeilennummer des Snippets (nur für VFP-SCX) |
| ADJUST | (N(5)) | ? |
| FILENAME | (C(50)) | Datei, in der das Symbol vorkommt. |
Mit Hilfe eines einfachen Programms läßt sich diese Datei daraufhin untersuchen, welche Symbolnamen mehr als 10 Zeichen haben und bis zum 10. Zeichen gleich heißen.
Eine Methode, die von vielen dBase-Umsteigern bei Einführung von FoxPro 2.0 angewendet wurde, um ihren Programmcode nach FoxPro zu übernehmen, bestand darin, die .PRG-Dateien in den FoxPro-Projektmanager einzubinden. Auf diese Weise wurde der für viele noch ungewohnte Maskeneditor umgangen. Das Programm war aber - abgesehen von den Änderungen, die sich durch die nicht 100%ige Sprachkompatibilität ergaben - ohne viel Aufwand direkt kompilier- und ablauffähig. Ein ähnliches Vorgehen ist beim Übernehmen von FoxPro 2.6-Projekten nach Visual FoxPro möglich. Diese Methode sei hier nur in Stichpunkten skizziert, da sie sicherlich nur für Sonderfälle relevant ist. Der Ablauf zum Erstellen einer Visual FoxPro-Applikation sähe dann wie folgt aus:
Öffnen des alten Projektes in FoxPro 2.6
Generieren aller Quellen in ein gemeinsames Verzeichnis
neues Projekt in Visual FoxPro anlegen
Hinzufügen aller in FoxPro 2.6 generierter Programme
Hinzufügen aller sonstiger Dateien (Tabellen, Berichte, Etiketten...).
Berichte und Etiketten müssen jedoch nach dem Einfügen in Visual FoxPro einmal
geöffnet werden, um sie in das Visual FoxPro-Format zu konvertieren. Sie
sind mit ‘REPORT FORM ...’ nicht lauffähig!
Hauptprogramm bestimmen
Projekt erstellen
fertig
In Visual FoxPro hat sich das Format der meisten Dateien, in denen die Informationen zu den einzelnen Modulen gespeichert sind, geändert. Das erfordert eine Konvertierung der Dateien und der in ihnen enthaltenen Informationen in das für Visual FoxPro lesbare Format. Die Konvertierung der Dateiformate geht automatisch vor sich. Für das Konvertieren der in diesen Dateien enthaltenen Programminformationen gibt es mehrere Wege, die einen mehr oder weniger großen Arbeitsaufwand erfordern.
Beim Öffnen von Projekten, die unter FoxPro 2.6 (DOS oder Windows) erstellt wurden, bietet VFP automatisch die Konvertierung aller in dem Projekt enthaltenen Dateien an
Mit Auswahl von ‘Full Conversion’ oder ‘Visual Conversion’ wird zunächst die Projektdatei geöffnet. Unterhalb des Verzeichnisses, in dem die Projektdatei abgelegt ist, wird ein Verzeichnis ‘OLD’ (bei nochmaliger Konvertierung ‘OLD1’ usw.) erstellt.
In dieses werden Kopien aller Dateien (Projektdateien, Maskendateien, Reportdateien), die einer Konvertierung bedürfen, in für FoxPro 2.6 lesbarer Form abgelegt. Die Sicherheitskopien bekommen dabei einen neuen Namen, der sich aus dem alten Namen der Datei ergibt, in dem aber der 2. Buchstabe der Erweiterung mit ‘2’ ersetzt wird.
Eine Konvertierung von .PRG-Dateien ist nicht notwendig. Der Programmcode ist nach wie vor im FoxPro-Editor les- und bearbeitbar. Beim Öffnen von Programm-, Dokument- und Abfragedateien aus dem Projektmanager heraus wird nun aber die gewählte Codepage in der .PJX-Datei gespeichert, eine wiederholte Auswahl der Codepage ist dann nicht mehr notwendig.
Die Daten für Visual FoxPro-Formulare (Forms), wie die Masken jetzt heißen, werden nach wie vor in .SCX-Dateien abgelegt. Allerdings hat sich das Format dieser Dateien stark verändert, was eine Konvertierung erfordert. Die Konvertierung wird automatisch angeboten, wenn eine FoxPro 2.6-Maskendatei mit ’MODIFY FORM ...’ geöffnet wird. Hier besteht eine Auswahlmöglichkeit zwischen ‘Full Conversion’ und ‘Visual Conversion’.
Bei der Full Conversion werden alle Codeteile der Ausgangsdatei in die entsprechenden Methoden der Visual FoxPro-Datei eingetragen. Für jeden Codesnippet-Typen hat Visual FoxPro ein spezielles ‘Kompatibilitäts’-Event, in dessen Methode der Code aus der FoxPro 2.6-Maske eingetragen wird.
Bei der Visual Conversion wird nur der ‘sichtbare’ Teil der Maskendefinition übernommen. Der Code muß dann neu entwickelt werden. Diese Möglichkeit ist dann sinnvoll, wenn man sich nur die Arbeit für den Neuaufbau des Layouts sparen möchte, aber die Möglichkeiten des neuen Eventmodells ausnutzen will.
Der Menüdesigner hat sich zwischen den Versionen von FoxPro nicht geändert. Auch das Format der Menüdateien ist gleich geblieben, so daß keine Konvertierung notwendig ist. Solange in Visual FoxPro keine Änderung am Menü gemacht wird, bleibt auch die .MNX-Datei selbst unangetastet, so daß sie sich auch unter FoxPro 2.6 wieder öffnen läßt. Wurden jedoch Änderungen vorgenommen, muß die .MNX mit ‘USE...’ geöffnet und mit einem ‘COPY TO ... TYPE FOX2X’ wieder in das FoxPro 2.6-Dateiformat umgewandelt werden.
Da Abfragen als .QPR-Dateien im Quellcode abgespeichert werden, gilt für sie das gleiche wie für Programmdateien.
Der Leistungsumfang des Berichts- und des Etiketteneditors hat sich nur geringfügig geändert. Trotzdem wird eine Konvertierung durchgeführt, da sich das Format der Umgebungsinformation verändert hat. Auch dabei wird eine Kopie der Originaldatei angelegt.
Die für die FoxProDOS oder FoxProWIN kompilierten .PLB und .FLL-Dateien lassen sich unter Visual FoxPro nicht weiterverwenden, sondern müssen mit Hilfe des Library-Construction-Kits neu kompiliert werden. Bei Bibliotheken, die von Drittanbietern zugekauft wurden, wird in aller Regel ein Update gekauft werden müssen.
Die schon in FoxPro 2.6 aus der Mode gekommenen Formatdateien dürften durch das in Visual FoxPro eingeführte Grid-Objekt nun völlig überflüssig werden. Im Zuge der Abwärtskompatibilität werden sie aber genau wie in FoxPro 2.6 noch unterstützt
Tabellen und Indizes lassen sich weiterhin im FoxPro 2.6-Format bearbeiten. Sie können auch mit FoxPro 2.6 wieder geöffnet werden, solange keiner der neuen Visual FoxPro-Feldtypen (Currency, DateTime, Double, Integer, Character (Binary), Memo (Binary)) benutzt und die Tabelle nicht in einen Datenbankcontainer eingefügt wurde. Wenn einer dieser neuen Feldtypen benutzt oder die Tabelle in eine Visual FoxPro-Datenbank eingefügt wurde, kann sie nur über ein ‘COPY TO ... TYPE FOX2X’ in das FoxPro 2.6-Format zurückkonvertiert werden. Dabei gehen natürlich alle Informationen, die die spezifischen Visual FoxPro-Features nutzen, wieder verloren.
Dateien aus anderen Programmen werden von Visual FoxPro nicht weiter konvertiert. Es ist aber aus dem Projektmanager heraus jetzt möglich, per Doppelklick auf den Dateinamen den zugehörigen Editor zu starten, wobei der Name der Datei gleich mit übergeben wird.
Wie in FoxPro 2.6 können auch .APP-Dateien in den Projektmanager eingebunden werden. Beim Doppelklick auf diese Dateien wird - so vorhanden - das zugehörige Projekt geöffnet, woraufhin wieder der Dialog ‘Konvertierung...’ erscheint. Von FoxPro 2.6 kompilierte Programme (.FXP, .SPX, .APP) sind in Visual FoxPro nicht ablauffähig, sondern müssen neu kompiliert werden.
Die Methode, die für die meisten Entwickler relevant sein dürfte, ist die Konvertierung von kompletten Projekten. Dabei werden die einzelnen Dateien wie oben beschrieben konvertiert. Auch die Konvertierung von FoxProDOS-Projekten ist möglich, allerdings treten dabei die gleichen Probleme (Zeichensätze, Bildschirmpositionen) auf, wie beim Transport von FoxProDOS nach FoxProWIN. Da die Umstellung der Masken auf Formulare und der damit zusammenhängende Umstieg auf eine neue Form des READ-Befehls die größten Anpassungen erfordert, sei hier noch auf das Ergebnis der ‘Vollständigen Konvertierung’ von Masken eingegangen.
Produkt des Konverters ist zunächst einmal die .SCX-Datei (mit zugehöriger .SCT). Außerdem erzeugt der Konverter noch eine .SPR-Datei, die als ‘Lader’ für das eigentliche Formular dient. Diese .SPR-Datei enthält im wesentlichen die Programmzeile ‘DO FORM ...’ Hat die Ursprungsmaske Abschlußcode, so wird der hinter dieser Programmzeile eingefügt. Enthalten die Prozeduren, die im Abschlußcode gespeichert sind, Befehle die auf Arrays referenzieren, so wird für diese Arrays eine ‘EXTERNAL’-Anweisung in das .SPR eingebaut.
Die .SCX-Datei ist ein komplettes Visual FoxPro FormSet (Formulargruppe), in dem die GET-Elemente in Steuerelemente umgewandelt wurden. Es wird immer - auch wenn die Maskengruppe nur aus einer Maske bestand - eine Formulargruppe erzeugt. Für jede in der FoxPro 2.6 Formulargruppe vorhandene Maske wird dann eine Form (Formular) angelegt. Dieses Formular wird von einem PageFrame (Seitenrahmen) vollständig ausgefüllt, auf dem sich eine Page (Seite) befindet. Auf dieser Seite wiederum finden die eigentlichen Controls (Steuerelemente) wie Buttons (Schaltflächen) und OptionButtons (Optionsfelder) ihren Platz
Die Formulargruppe erhält in der Eigenschaft WindowType den Wert 2 (FoxPro 2.6 READ-kompatibel) oder 3 (READ-modal) zugewiesen. Nur, wenn diese Eigenschaft einen der beiden Werte enthält, läuft Visual FoxPro im READ-Kompatibilitätsmodus, was die Ausführbarkeit von Programmzeilen, die z.B. ein ‘SHOW GET ... PROMPT ...’ enthalten, ermöglicht.
Um den Code in der alten Form lauffähig zu halten, wird der Inhalt der einzelnen Codeabschnitte speziellen Ereignissen (die wie bisher in Memofeldern der .SCX-Datei abgelegt sind) zugeordnet. Die Ereignisse, die für die Read-Kompatibilität vorgesehen sind, heißen ReadActivate (Code der READ ACTIVATE-Klausel), ReadWhen (Code der READ WHEN-Klausel), ReadValid (Code der READ VALID-Klausel), ReadDeactivate (Code der READ DEACTIVATE-Klausel) und ReadShow (Code der READ Show-Klausel).
Der Code der Initialisierungsprozedur wird in verschiedenen Methoden gespeichert: die Zeilen, die auf die ‘#SECTION 1’-Anweisung folgen, werden in die LOAD-Methode der Formulargruppe geschrieben; die Zeilen, die auf ‘#SECTION 2’ folgen, kommen in die LOAD-Methode des Formular. Die Quellcodes der FP 2.6-Masken werden wie in der folgenden Tabelle beschrieben in Methoden von Visual FoxPro umgewandelt:
| Quelle FoxPro 2.6 | Methode Visual FoxPro |
| Maske.Setupcode #SECTION1 | FormSet.Load |
| Maske.Setupcode #SECTION2 | Form.Load |
| Maske.Cleanup | FormSet.Unload |
| Maske.Deactivate | FormSet.ReadDeactivate |
| Maske.Activate | FormSet.ReadActivate |
| Maske.Valid | FormSet.ReadValid |
| Maske.When | FormSet.ReadWhen |
| Maske.Show | FormSet.ReadShow |
| Get.When | Objekt.When |
| Get.Valid | Objekt.Valid |
Die in die Formulare eingefügten Seiten repräsentieren die Readlevel. Sie sind notwendig, um Befehle auf Read-Ebene, wie ‘@ ... GET ... ‘ zu handhaben.
Die mit der vollständigen Konvertierung erzeugten Formulare sind lauffähig, machen aber keinen Gebrauch von der Vielzahl der neuen Ereignisse, sondern emulieren das Verhalten der FoxPro 2.6-Masken.
Aus den Daten, die mit ‘Umgebung speichern’ in der FoxPro 2.6-Maske abgelegt wurden, wird ein neues Objekt der Klasse ‘DataEnvironment’ angelegt. In ihm werden alle Tabellen und die Relationen, die für das Formular benötigt werden, abgelegt.
Der zweite Weg, Masken in Formulare zu überführen, ist die ‘Visuelle Konvertierung’. Im Gegensatz zur Vollständigen Konvertierung werden hier nur die sichtbaren Objekte in die Formulare eingefügt; aller Programmcode in den alten Maskenabschnitten geht verloren. Bei dieser Konvertierungsart werden auch keine Hilfskonstruktionen wie Formulargruppen oder Seitenrahmen erzeugt. Das Ergebnis dient hauptsächlich dazu, die Kleinarbeit des Formularlayouts zu übergehen und mit der Programmierung direkt auf das neue Eventmodell von Visual FoxPro aufzusetzen
Die Einführung von GenscrnX hat die Möglichkeiten bei der Generierung von Maskenprogrammen erheblich erweitert. Die zusätzlichen Features wurden meist durch das Generieren von zusätzlichen Programmzeilen bereitgestellt. Da in VFP kein Quellcode mehr generiert wird, ist di Manipulation der .SCX-Datei auf diesem Weg nicht mehr möglich. Viel von der Leistungsfähigkeit von GenscrnX-Direktiven ist aber jetzt in der ein oder anderen Form direkt als Funktionalität von Visual FoxPro integriert. Durch die Vielzahl neuer Controls und die ihnen eigenen Properties kann das Erscheinungsbild von VFP-Formularen auch zur Laufzeit ohne spezielle Tricks verändert werden. Eine Bearbeitung der .SCX-Datei während der Formulargestaltung ist aber weiterhin möglich. Dazu dienen die neu eingeführten ‘Builders’ (deutsch: ‘Steuerelementassistenten’), die mit VFP neu eingeführt wurden.
In der Tabelle sind verschiedene Standard-GenscrnX-Anweisungen aufgeführt.
| GenscrnX-Direktiven |
||
|---|---|---|
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> Anweisung |
Ort | Erläuterung |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right: solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> #:SECTION 3 | SETUP | Nicht mehr benötigt. Statt dessen Code in Init-Methods verwenden. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:AUTORUN |
SETUP | Nicht mehr benötigt. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:SET OPENFILES ON | OFF |
SETUP | Property AutoOpenTables im DataEnvironment |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:SET CLOSEFILES ON | OFF |
SETUP | Property AutoCloseTables im DataEnvironment. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:SET MODAL ON | OFF |
SETUP | Property WindowType des Formulars. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:OUTFILE |
SETUP | Nicht mehr benötigt. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:DEFLIB |
SETUP | Nicht mehr benötigt. Stattdessen hat jedes Objekt ein Property ParentClass. Wenn die Parentclass benutzerdefiniert ist, steht die Klassenbibliothek im Property ClassLib. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:SCXDRVn |
SETUP | Dei Funktionalität der eingebundenen Treiber muß im Einzelfall geprüft werden, ist aber meist überflüssig (z.B. wird der TAB-Treiber von Stephen Black komplett durch das neue PageFrame- (Seitenrahmen-) Objekt ersetzt). |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:MEMVAR |
SETUP | Wird ersetzt durch Möglichkeiten des Buffering (Property BufferMode im DataEnvironment). |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:NOWCLAUSES |
SETUP | Wird ersetzt durch die Möglichkeit, die Properties Top, Left, Height, Width des Formulars zur Laufzeit verändern zu können. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:DEFOBJ |
COMMENT | Wird ersetzt durch die Möglichkeit, das Property Name zur Laufzeit verändern zu können. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:FUNCTION |
COMMENT | Wird ersetzt durch den jedem Event zugeordnten Code in den Methods. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:IF |
COMMENT | Wird ersetzt durch Code für Init-Event |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:SIZE |
COMMENT | Wird ersetzt durch die Möglichkeit, die Properties Top, Left, Height, Width der Controls zur Laufzeit verändern zu können. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.0pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:PICTURE |
COMMENT | Wird ersetzt durch InputMask-, DisabledPicture-, DownPicture-, DragIcon-, Picture- und Format-Properties. |
| solid windowtext 1.5pt;border-bottom:solid windowtext 1.5pt;border-right:
solid windowtext 1.0pt;padding:0cm 3.5pt 0cm 3.5pt'> *:REFRESH |
COMMENT |
Da im neuen READ EVENTS keine Show-Klausel existiert, werden die Refreshs der Formularobjekte durch Ansprechen der den Objekten zugehörigen Methode Refresh( ) erreicht. |
Das Einfügen von Objekten zu Dokumentationszwecken, die mit der GenscrnX-Anweisung „*:DELETE“ wieder gelöscht werden, klappt in Visual FoxPro nicht mehr. Man kann zwar das Visible-Property solcher Objekte aus 0 setzen, das Objekt wird aber trotzdem instanziiert und kostet auch Speiherplatz.
Wenn der Name einer Maske mit einer Makrosubstitution gebildet wird, muß diese Maske vor dem Konvertieren bearbeitet werden: der Name muß durch einen festen Text (einen normalen Namen) ersetzt werden. Dann kann die Maske konvertiert werden. Die vorherige Makrosubstitution kann dann in den Init-Code des Formulars in der Form This.Name = <Makro> wieder eingefügt werden.
Die Einführung von Visual FoxPro bringt neue Möglichkeiten in allen Bereichen der DBMS-Entwicklung.
Die größte Umstellung für den Entwickler dürfte die neue Syntax der OO-Erweiterungen in Visual FoxPro sein. Die Konvertierung von Projekten kann als Einstieg in die objektorientierte Programmierung nur der Anfang sein. Visual FoxPro bietet hier aber immerhin die Möglichkeit vorhandenen Programmcode Stück für Stück umzusetzen. Wichtig für diesen Umstellungsprozess ist, daß man die Grundlagen der Objektorientierung verstanden hat. Als Hilfsmittel für das Experimentieren mit den neuen Sprachkonstrukten ist der Aufbau von FoxPro als Interpreter sehr gut geeignet. Im Befehlsfenster lassen sich z. B. Objekte instanziieren; auf diese Objekte und ihre Attribute kann dann auch wieder über Befehlseingabe zugergriffen werden.
Der erste Schritt zum Überführen des alten Projektes in das VFP-Programmiermodell kann die Umstellung der READ-Modells sein. Hier muß der Code aus den Kompatibilitäts-Events umgeschrieben werden in die neuen Ereignisse, die von ‘Read Events’ unterstützt werden. Dazu muß auch die Aufteilung der Formulare aus FormSets, Forms und PageFrames aufgehoben werden. Das WindowType-Property muß auf einen der ‘Read Events’-konformen Werte eingestellt werden. Im Rahmen der Erstellung von Klassenbibliotheken kann man dann schon das ein oder andere Objekt aus der Klassenbibliothek einsetzen.
Die Masken, die von FoxPro 2.6 übernommen wurden, haben noch keine den Objekten zugrundeliegenden benutzerspezifischen Klassendefinitionen. Aller Code, der die Snippets eingegeben wurde, wurde in die Objekte in den Formularen übernommen. Um die Vorteile der Vererbung wahrnehmen zu können, können die Gemeinsamkeiten der einzelnen Objekte in Klassendefinitionen zusammengefasst werden. Daraus entwickelt sich automatisch eine erste Klassenbibliothek, die den jereiligen Anforderungen angepasst ist.
Bei der Übernahme von Projekten in VFP gehört die Erstellung einer .DBC-Datei zu den wichtigsten Arbeiten. Die Datenbankcontainer bieten z. B. die Möglichkeit, zu den Feldern der in ihnen gespeicherten Tabellen Klartexte als Feldnamen zu definieren. Auch das Ablegen von Views und die darauf aufstzende Verwendung als DataEnvironment kann für einzelne Formulare eine Vereinfachung bringen. Ist der Datenbankcontainer einmal erstellt, bietet sich das Überführen von RI-Programmierung in im Container abgelegten Code an.
Visual FoxPro führt einige neue Controls ein. Das Grid-Objekt, das die komplizierte Programmierung einer Kombination von Masken und Browse-Fenstern erübrigt, ist sicher eins der wichtigsten. Auch die PageFrames sind eine große Hilfe bei der Oberflächengestaltung. Durch diese neuen Controls wird sich das Erscheinungsbild der meisten Applikationen stark verändern.
Auch für das ‘Drag & Drop’ bietet VFP mit seinen zusätzlich abfragbaren Ereignissen verbesserte Möglichkeiten.