Konvertierung von Anwendungen aus VFP 3.0 nach VFP 5.0 / 6.0

von Susan Graham, Microsoft

übersetzt von Mathias Gronau

Überblick

Die meisten Entwickler hatten keine Probleme, ihren in Visual FoxPro 3.0 entwickelten Code auch in Visual FoxPro 6.0 einzusetzen. Trotzdem gibt es einige Punkte, die Sie beachten sollten.

Der Objektcode wurde in Visual FoxPro 6.0 geändert. Daher müssen Sie alle Programmdateien (.PRG), Formulare (.SCX), Abfragen (.QPR), Menüs (.MPR), Berichte (.FRX), Datenbankcontainer (.DBC) und Klassenbibliotheken (.VCX) neu kompilieren. Die Kompilierung erfolgt automatisch, wenn Sie eine dieser Dateien ändern, instanziieren oder in Visual FoxPro 6.0 ausführen.

Wenn Sie ein in Visual FoxPro 3.0 erstelltes Projekt öffnen, ruft Visual FoxPro 6.0 automatisch den Konverter CONVERT.APP auf, den Sie im Verzeichnis von VFP finden. Dieser Konverter wandelt das Projekt mit allen Inhalten in das neue Format um. Auch beim Öffnen einzelner Berichte oder Etiketten wird der Konverter gestartet. Wenn Sie ein Kommando wie MODIFIY CLASS oder MODIFY FORM absetzen, kompiliert Visual FoxPro 6.0 die Datei vor dem Öffnen neu.

Auf welche Punkte müssen Sie speziell achten?

  • Die Vorgabewerte der Eigenschaften FontBold, FontSize und ColorSource haben sich geändert.

    • Eigenschaft

    Vorgabewert in VFP 3.0

    Vorgabewert in VFP 6.0

    FontBold

    True

    False

    FontSize

    10

    9

    ColorSorce

    0

    4


  • Label.Refresh() tritt in Label.PARENT.Refresh() nicht mehr auf.
  • In Visual FoxPro 3.0b konnten Sie einem Label eine Methode Refresh() hinzufügen und sie im Code an eine "ControlSource" "binden". Das Label erneuerte seine Caption dann beim THISFORM.Refresh() automatisch. Diese Möglichkeit besteht in Visual FoxPro 6.0 für Kontrollelemente, die nicht über eine native Methode Refresh verfügen, nicht mehr.
  • In Visual FoxPro 6.0 können auch Seiten den Focus erhalten.

In Visual FoxPro 6.0 können auch in PageFrames eingebundene Seiten den Fokus erhalten (um die Caption des Tabs erscheint das Rechteck, das den Fokus anzeigt). Der Code, der sich im Ereignis When oder GotFocus des ersten Kontrollelements in der Aufrufreihenfolge einer Seite befindet, wird in Visual FoxPro 6.0 nicht mhr ausgeführt, wenn die Seite den Fokus erhält. Wenn Ihre Anwendung erwartet, dass das erste Objekt einer Seite den Fokus erhält, erreichen Sie dies, wenn Sie den folgenden Code in das Ereignis Activate der Seite einfügen:

    KEYBOARD “{TAB}“ PLAIN

Alternativ dazu können Sie im Activate der Seite auch die folgende Zeile eintragen:

    THIS.Controls(1).SetFocus()

Wenn Sie sich für dieses Vorgehen entscheiden sollten Sie aber sicherstellen, dass das erste Objekt der Seite über die Methode SetFocus() verfügt. Andernfalls generiert Visual FoxPro einen Fehler, da es die Methode nicht findet.

  • Wenn das Init eines Kontrollelements False (.F.) zurückgibt, wird das Init des Formulars aufgerufen.

Gab in Visual FoxPro 3.0b das Init eines Kontrollelements in einem Formular False zurück, wurde das Ereignis Init nie ausgeführt und das Formular wurde nicht instanziiert. Geschieht dies unter Visual FoxPro 6.0, wird das Init des Formulars ausgeführt, also Code, dessen Ausführung Sie an dieser Stelle nicht erwartet hätten.

Diese Änderung war geplant. Microsoft ging davon aus, dass in der überwiegenden Zahl der Fälle die Entwickler das Formular auch dann ausführen wollen, wenn ein Init eines Kontrollelements False zurückgegeben hat. Wenn Sie dieses Verhalten ändern wollen, überprüfen Sie im Init des Formulars die Existenz aller Kontrollelemente und geben Sie False zurück, wenn das Kontrollelement auf dem Formular nicht vorhanden ist.

    IF TYPE("THISFORM.Control1")="U"
     * Control1 is the object that must RETURN .F.
     * exist to allow the form to run
    ENDIF
     
  • Wenn eine Basisklasse in Visual FoxPro 3.0 nicht über das Ereignis ProgrammaticChange und die Eigenschaft Value verfügte, konnte man diese hinzufügen und sie arbeiteten als ob sie nativ zu dieser Klasse gehören würden.

Einige Entwickler haben dieses undokumentierte Feature benutzt, um damit die Ausführung des Code von SetAll() zu unterstützen. Ein Beispiel dafür ist die Anweisung "ExecuteAll(MyMethodName)", wobei es sich bei MyMethodName um ein benutzerdefiniertes ProgrammaticChange-Ereignis handelt.

Ein weiteres Beispiel: SetAll("Value", 0, "MyClass") in einem Header-Objekt in einem Grid würde den Code in allen Methoden ProgrammaticChange aller Headerobjekte des Grid ausführen. Dabei spielt es keine Rolle, dass die Eigenschaft Value im Grunde keine Aufgabe erfüllt. Sie bietet lediglich die Möglichkeit Code auszuführen, der jeden Header (und jede Spalte) des Grid betrifft, ohne den Code jeder Spalte einzeln aufrufen zu müssen.

Dieses undokumentierte Feature ist in Visual FoxPro 6.0 nicht länger verfügbar. Sie können auf diese Weise nur noch vorgehen, wenn das Kontrollelement oder Objekt über das Ereignis ProgrammaticChange und die Eigenschaft Value verfügt.

Code, der auf diesem Feature aufgebaut war, kann in eine FOR...ENDFOR-Schleife eingefasst werden, um den Code der einzelnen Objekte einzeln aufzurufen.

  • Visual FoxPro 3.0 hat sich so verhalten, als wäre AutoYield auf .T. gesetzt.

Visual FoxPro 3.0 hat noch nicht über die Eigenschaft AutoYield verfügt. Es verhielt sich aber so, als wäre sie auf .T. gesetzt. In Visual FoxPro 6.0 enthält AutoYield .T. als Vorgabewert.

Wenn ein Formular in Visual FoxPro 6.0 ein ActiveX-Control enthält, sollte AutoYield auf .F. gesetzt werden. Dadurch wird verhindert, dass Ereignisse für ein ActiveX-Steuerelement zwischen den Zeilen des benutzerdefinierten Programmcodes ausgeführt werden. Ist AutoYield .T. kann ein Klick auf ein ActiveX-Control während der Ausführung benutzerdefinierten Codes ein Ereignis für das ActiveX-Control auslösen, während der benutzerdefinierte Programmcode für dieses Ereignis ignoriert wird. Dadurch können unerwünschte und unerwartete Ergebnisse hervorgerufen werden.

  • Visual FoxPro 6.0 ändert bei Menüs, die mit der Anweisung DEFINE POPUP erstellt wurden, die Farben der Titelleiste.

In Visual FoxPro 6.0 ändert DEFINE POPUP die Farbe der Titelleiste auf die Farbe der inaktiven Titelleiste. Visual FoxPro 3.0b hatte dieses Verhalten nicht. Kontextmenüs, die in Visual FoxPro mit der Anweisung DEFINE POPUP SHORTCUT erstellt wurden, ändern die Farbe der Titelleiste nicht.

  • Das Schließen einer Tabelle mit nicht übertragenen Änderungen führt in Visual FoxPro 6.0 ein TABLEREVERT() aus.

Wird in Visual FoxPro 3.0b ein Formular geschlossen, das gepufferte aber noch nicht in der Tabelle gespeicherte Daten enthält, beendet sich das Formular und es wird eine Fehlermeldung generiert. Sie müssen anschließend mit SELECT auf die Tabelle wechseln und ein TABLEREVERT() absetzen, bevor Sie Visual FoxPro 3.0b beenden können.

In Visual FoxPro 6.0 generiert das gleiche Szenario keine Fehlermeldung und es wird ein impliziter TABLEREVERT() ausgeführt. Da keine Fehlermeldung generiert wird könnten Sie der Meinung sein, dass die Änderungen übertragen wurden. Tatsächlich wurden die Änderungen aber verworfen. In Visual FoxPro 6.0 sollten sie sicherstellen, dass Anwendungen, die mit dem Buffering arbeiten, es den Formularen nicht ermöglichen, sich zu beenden, ohne die Änderungen an den Daten vorher zu übertragen.

  • Die Anweisung COMPILE REPORT ist in Visual FoxPro 3.0 nicht verfügbar.

Die Anweisung COMPILE REPORT wurde erst in Visual FoxPro 5.0 eingeführt und wird von Visual FoxPro 3.0 nicht unterstützt. Mit Visual FoxPro 6.0 kompilierter Code, der in Berichten oder Etiketten enthalten ist, kann mit dem folgenden Programm in das Format von Visual FoxPro 3.0 kompiliert werden. Kopieren Sie den folgenden Code in eine Programmdatei und führen Sie diese Datei aus dem Befehlsfenster heraus aus. Dabei übergeben Sie den Namen des Berichts oder des Etiketts dem Programm als Parameter. Beispiele dafür finden Sie im Header des folgenden Programms.

    ******************************************************
    *                 CONVREPO.PRG
    *
    * Program to compile Visual FoxPro 5.0 .frx or .lbx
    * file to run under Visual FoxPro 3. This is necessary
    * only if the report or label contains code in any of
    * its DataEnvironment methods.
    *
    * Usage: DO CONVREPO WITH <.frx or .lbx file
    * including extension>
    *
    * Example:  DO CONVREPO WITH "myreport.frx"
    *
    ******************************************************
     
    LPARAMETER lcFrxName
    LOCAL lcAlias, lcTmpFile
    IF (TYPE('lcFrxName') = "C" AND;
    UPPER('frx')$UPPER(lcFrxName)) OR ;
          (TYPE('lcFrxName') = "C" AND;
    UPPER('lbx')$UPPER(lcFrxName))
     
       IF NOT FILE(lcFrxName)
          =MESSAGEBOX('The file '+ UPPER(lcFrxName) + ' ;
             does not ' + 'exist in the default ;
             directory. '+ CHR(13)+ ;
             'Please pass a valid report '+ ;
             'or label filename, including extension, ;
             to this program!' ,48, "Report/Label Code ;
             Compiler")
          RETURN
       ENDIF
     
       USE (lcFrxName)
       lcAlias = ALIAS()
       * Look for any Data Environment object's records
       SCAN FOR NAME='dataenvironment' ;
             OR NAME='cursor' ;
             OR NAME='relation'
          IF !EMPTY(TAG)             && Is there any code?
             lcTmpFile = SYS(3)
             COPY MEMO TAG TO (lcTmpFile+'.PRG')
             * Copy to temp .prg
             COMPILE (lcTmpFile)      && Compile it
             APPEND MEMO tag2 ;
                FROM (lcTmpFile+".FXP") OVERWRITE
                * Write it back to .frx/.lbx
             ERASE (lcTmpFile+".PRG") && Delete temp files
             ERASE (lcTmpFile+".FXP")
          ENDIF
       ENDSCAN
       USE IN (lcAlias)
       SET MESSAGE TO "Recompile completed"
       WAIT "" TIMEOUT 2
       SET MESSAGE TO
    ELSE
     
       =MESSAGEBOX('Please pass a report or label ;
          filename, '+ 'including extension, to this ;
          program!' ,48, "Report/Label Code Compiler")
       RETURN
    ENDIF
    RETURN
    *
    * End of CONVREPO.PRG

Zusätzliche Überlegungen zur Konvertierung von Anwendungen in Visual FoxPro 6.0

  • BUILDAPP.PRG ist eins der Tools von Visual FoxPro. Es extrahiert für die Distribution die Codes der Methoden und Ereignisse aus den .SCX- und .VCX-Dateien. Es wird von Visual FoxPro 6.0 nicht benötigt. Hier werden die Sourcen automatisch aus den .APP- und .EXE-Dateien extrahiert, wenn Sie auf der Seite Projekt des Dialogs Projektinformation das Kontrollkästchen Debug-Info deaktivieren.
  • In Visual FoxPro 6.0 erstellt die Funktion AFIELDS() ein Array mit 16 Spalten und stellt damit mehr Informationen über die Struktur der Tabelle zur Verfügung als in Visual FoxPro 3.0. Dort erstellte diese Funktion ein Array mit lediglich 11 Spalten. Für zusätzliche Informationen über die zusätzlichen Spalten vergleichen Sie bitte die Hilfedatei.
  • Einige Bitmaps, die in Visual FoxPro 3.0 korrekt angezeigt werden, werden in Visual FoxPro nicht richtig dargestellt. Wenn dieser Fall eintritt, benutzen Sie ImageEdit, ändern Sie mindestens ein Pixel des Bildes und speichern Sie das Bitmap.

Visual FoxPro 3.0 und Visual FoxPro 6.0 parallel nutzen

Wollen Sie Visual FoxPro 3.0 und 6.0 gleichzeitig einsetzen, gehen Sie folgendermaßen vor:

  1. Erstellen Sie unterschiedliche Projekte, für jede Version eins. Beachten Sie dabei, dass Sie aus beiden Projekten auf die gleichen Dateien verweisen können.
  2. Bevor Sie Dateien innerhalb des Projekts ändern oder eine Anwendung aus dem Projekt erstellen, erstellen Sie das gesamte Projekt mit Hilfe der aktivierten Option "Alle Dateien neu kompilieren" in der Dialogbox "Erstellungsoptionen" neu.
  3. Benutzen Sie keine Features, über die lediglich Visual FoxPro 6.0 verfügt.
  4. Beachten Sie die oben beschriebenen Unterschiede zwischen Visual FoxPro 3.0 und Visual FoxPro 6.0. Versuchen Sie, die Differenzen zu vermeiden oder setzen Sie die Anweisung DO CASE ein, um unterschiedlichen Code für die jeweilige Version auszuführen.

Einen weiteren Artikel zu diesem Thema finden Sie unter der Artikel-ID Q162076 in der Knowledge-Base unter der URL www.microsoft.com/kb/. Dort wird die Konvertierung von Visual FoxPro 3.0 auf Visual FoxPro 5.0 behandelt.

Zusammenfassung

Die Umstellung einer Anwendung von Visual FoxPro 3.0 auf 6.0 sollte eigentlich glatt über die Bühne gehen. Visual FoxPro 6.0 bietet die Vorteile einer erhöhten Geschwindigkeit, seit der Version 5.0 eine neue Debug-Umgebung, OLE Automation und neue Datenbank-Funktionalitäten. Für weitere Informationen über Visual FoxPro 6.0 besuchen Sie bitte die Visual FoxPro-Website auf www.microsoft.com/vfoxpro/.

Danksagung

Die folgenden Anwender haben Informationen für diesen Artikel zur Verfügung bereitstellt, Probleme aufgezeigt, Code zur Verfügung gestellt und auf notwendige Änderungen hingewiesen: Drew Speedie, Mac Rubel, Lisa Slater Nicholls, Paul Maskens, Mike Feltman, Rainer Becker, Rick Strahl, Ken Levy, Jim Saunders, Calvin Hsia, und Ken Tittle