Konvertierung von FoxPro 2.6

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 und von Microsoft auch umgesezte Abwärts-Kompatibilität erlaubt es jedoch, bereits bestehende FoxPro 2.6-Projekte in die neue Umgebung zu übernehmen. Durch die neuen Konzepte ist das aber nicht 1 zu 1 möglich, sondern es müssen viele Dinge beachtet werden, um die neuen Möglichkeiten nutzen zu können.

Auf den ersten Blick hat sich in der Entwicklungsumgebung von VFP nicht viel geändert: es gibt das vertraute Menüsystem, das Befehlsfenster, die Möglichkeit, Programme zu editieren und ablaufen zu lassen. Die meisten Komponenten haben ihre Funktionalität aber z.T. erheblich verändert:

Auch in VFP ist der Projektmanager die zentrale Einrichtung, um eigene Entwicklungen handhaben zu können.

Im Vergleich zum FP 2.6-Projektmanager gliedert sich die Liste der an dem Projekt beteiligten Dateien in mehrere Teilabschnitte:

Das Fenster des Projektmanagers läßt sich in der Größe verändern. Mit Hilfe des Buttons an der rechten oberen Ecke kann der Projektmanager auf minimale Größe gebracht werden. Die Aufrufe der Funktionen, die sonst über die Schaltflächen rechts der Dateilisten erreichbar sind, können nun auch über das mit der rechten Maustaste aufrufbare Kontextmenü erfolgen. Ist der Projektmanager auf volle Größe gebracht, weden im unteren Teil des Fensters die Beschreibung und der Pfad zu der aktuellen Datei angezeigt.

Der Datenbankdesigner ist komplett neu in Visual FoxPro. Er besteht aus mehreren Bildschirmen: Dem Designer selbst, der eine Übersicht über die Tabellen der Datenbank und ihre Relationen bietet, dem Tabellendesigner, der den Dialog „Tabelle modifizieren" aus FoxPro 2.6 ersetzt, dem Formular für Relationen und dem Dialog für die Erstellung des RI-Codes.

Der RI-Builder generiert Programmcode, der in der .DBC-Datei abgelegt wird. Dieser Programmcode wird immer, wenn ein Datensatz einer Tabelle, die Mitglied einer Datenbank ist, gelöscht, eingefügt oder geändert werden soll, ausgeführt. Die referenzielle Integrität wird von Visual FoxPro also unter allen Umständen sichergestellt.

Der Formulardesigner dient dem Erstellen von Formularen oder Formulargruppen. Seine Bedienung ähnelt der des Formulardesigners in FoxPro 2.6. Neu ist allerdings das Property-Sheet (Eigenschaftsfenster), in dem sich die Eigenschaften aller Objekte auf dem Formular beeinflussen lassen.

Der Code, der für die Ereignisse vorgesehen ist, wird auch in VFP 3.0 in Memofelder der .SCX-Datei eingegeben. Anders als in der vorherigen Version sind die Bearbeitungsfenster aber nicht mehr voneinander getrennt, sondern per Bildá - und Bildâ -Taste läßt sich zum jeweils nächsten Codestück blättern.

Der Klassendesigner ist dem Formulardesigner auf den ersten Blick sehr ähnlich. In ihm lassen sich aber nicht nur Formulare oder Formulargruppen erstellen, sondern Klassendeinitionen aller Art, auch für nicht-visuelle Klassen.

Der Menü- und der Reportgenerator haben sich in der neuen FoxPro-Version nur wenig geändert. Aus der visuell erstellten Menüdefinition wird nach wie vor ein .MPR-Programm generiert.

In Visual FoxPro gibt es, wie schon in den meisten anderen Microsoft-Produkten nun auch Toolbars (Symbolleisten). Symbolleisten sind Container für andere Controls (i. d. R. Buttons). Sie haben die Eigenschaft, daß sie sich in ihren Seitenverhältnissen verändern oder an den Bildschirmrändern andocken lassen. Die in ihnen enthaltenen Objekte werden dann jeweils neu angeordnet.

Das Verhalten der Arbeitsumgebung läßt sich in vielen Punkten beeinflussen. Die meisten Optionen sind über das Menü „Tools - Options..." zugänglich.

Vor der Konvertierung eines gesamten Projektes sollte dieses mit Hilfe des FP2.6 Projektmanagers auf Vollständigkeit und Fehlerfreiheit überprüft werden. Dazu lässt man am besten das gesamte Projekt neu erstellen und alle .SPR- und .MPR-Programme neu generieren. Auftretende Referenzprobleme sollten sofort beseitigt werden, notfalls über dummi-Dateien.

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

Der Documenting Wizard legt unter anderem eine .DBF mit einem Einträgen von jedem Auftreten jeden Symbols (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:

In Visual FoxPro 3.0 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 3.0 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.

Projektdateien 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 Formulars.

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

GenscrnX-Direktiven
Anweisung	Ort	Erläuterung
#:SECTION 3	SETUP	Nicht mehr benötigt. Statt dessen Code in Init-Methods verwenden.
*:AUTORUN	SETUP	Nicht mehr benötigt.
*:SET OPENFILES ON \| OFF	SETUP	Property AutoOpenTables im DataEnvironment
*:SET CLOSEFILES ON \| OFF	SETUP	Property AutoCloseTables im DataEnvironment.
*:SET MODAL ON \| OFF	SETUP	Property WindowType des Formulars.
:OUTFILE :PRG	SETUP	Nicht mehr benötigt.
:DEFLIB :INCLIB *:BASLIB	SETUP	Nicht mehr benötigt. Stattdessen hat jedes Objekt ein Property ParentClass. Wenn die Parentclass benutzerdefiniert ist, steht die Klassenbibliothek im Property ClassLib.
*: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).
*:MEMVAR	SETUP	Wird ersetzt durch Möglichkeiten des Buffering (Property BufferMode im DataEnvironment).
*:NOWCLAUSES #WCLAUSES	SETUP	Wird ersetzt durch die Möglichkeit, die Properties Top, Left, Height, Width des Formulars zur Laufzeit verändern zu können.
*:DEFOBJ	COMMENT	Wird ersetzt durch die Möglichkeit, das Property Name zur Laufzeit verändern zu können.
:FUNCTION :ENDFNCT	COMMENT	Wird ersetzt durch den jedem Event zugeordnten Code in den Methods.
*:IF	COMMENT	Wird ersetzt durch Code für Init-Event
*:SIZE	COMMENT	Wird ersetzt durch die Möglichkeit, die Properties Top, Left, Height, Width der Controls zur Laufzeit verändern zu können.
*:PICTURE	COMMENT	Wird ersetzt durch InputMask-, DisabledPicture-, DownPicture-, DragIcon-, Picture- und Format-Properties.
*: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.

Zur Erklärung: VFP trägt den Namen der Form in die Parent Properties der darunterliegenden Objekte ein. Mit dem eingetragenen Makrostring kann VFP aber weder zur Design- noch zur Laufzeit etwas anfangen und meldet, daß das Makro nicht ausgewertet werden kann. Wenn man das manuell mit use <Form> korrigiert, beschwert VFP sich darüber, daß es im jeweils nächsten Datensatz das Parent property nicht auswerten kann (dies passiert dann mit allen Feldern auf dem Formular).

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. Einen ersten Einblick erzeugt der Formularkonvertierer selbst aus dem alten Code in der Show-Routine der FP2.6-Masken.
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.

Mit der Konvertierung eines bestehenden Projektes ist nur der erste Schritt in die Entwicklung mit VFP getan. Die Konvertierung alleine ermöglicht aber noch nicht das Ausnutzen der vielen neuen Möglichkeiten.

Sie bietet sich hauptsächlich für bereits in FP2.6 abgeschlossene Entwicklungen an, an die sich eine mittel- bis langfristige Wartungsphase anschliessen soll. Während dieser Phase können die Applikationen als Hybride mit einem Teil Foundation-Read kompatiblen Codes und zum Teil schon VFP-konformen, klassenbasierten Formularen weitergepflegt werden. In dieser Wartungsphase können dann die Formulare und die darin befindlichen Controls Stück für Stück als Klassendefinitionen erstellt werden, was dann die Umstellung aller FP2.6-Masken in VFP-Formulare ermöglicht.

Bei neu zu erstellenden Projekten lohnt eine Übernahme von in FP2.6 entwickelten Standard-Codeteilen nur im Einzelfall. Die neuen Möglichkeiten der OOP machen ein Neucodieren vieler Funktionen als Klassendefinition wünschenswert. Hier kann eine alte Programmstruktur oft nur als Auflistung der benötigten Funktionalität dienen.