Compile & Co. Was bringt das
Service-Pack 3

Einführung

Die Visual FoxPro Version 6.0 ist jetzt seit einem guten Jahr auf dem Markt. Wie bei jeder neuen Version eines Softwareproduktes gab es einige Probleme und Schwierigkeiten, die mit dem Service-Pack 3 beseitigt worden sind. Das SP3 ist aber nicht nur eine Fehlerbereinigung, es sind auch einige neue, interessante Features enthalten.

• xBase-Updates Das SP3 stellt Updates für die folgenden xBase-Komponenten zur Verfügung: Setup-Assistent: Unterstützung für Multithred-Server Web Publishing Assistent: Speichern und Wiederverwendung von Formatvorlagen Anwendungsgenerator: Projektgenerator-Hook und erweiterte Benutzeroberfläche Erfassungsprotokoll-Profiler: Neue Methoden und bessere Protokollierung


• Neue und erweiterte Sprachelemente Einige neue Sprachelemente sind hinzugekommen, einige Sprachelemente wurden erweitert. Diese werden auf den nächsten Seiten noch ausführlicher besprochen.


• Server Ein wesentlicher Aspekt von Service Pack 3 liegt bei Multithread-Servern (COM-Objekten). Die Ausrichtung von Visual FoxPro als Middletier-System in 3-Tier Anwendungen verwenden Visual FoxPro MTDLL-Server mit IIS, ASPs, FoxISAPI, MTS und MSMQ.


• ActiveX-Steuerelemente Die Unterstützung von ActiveX-Steuerelementen wurde weitgehend verbessert, damit das OleControl-Steuerelement mit anderen Typen von ActiveX-Steuerelementen, wie z. B. Microsoft® Hierarchical FlexGrid, zusammenarbeiten kann.

Die folgenden Abschnitte geben einen Überblick über die Neuigkeiten des Service-Packs 3 und bewerten deren Funktionalität bezüglich Ihrer Einsetzbarkeit für die Entwicklung von Anwendungen. Weiterhin wird auf einige ausgewählte Probleme eingegangen, die durch das Service-Pack 3 beseitigt worden sind.

Neue und Erweiterte Sprachelemente

Das Visual FoxPro 6 SP3 enthält die folgenden neuen und erweiterten Sprachelemente:

Erweiterungen des COMPILE-Befehls

Der COMPILE-Befehl ist jetzt zur Laufzeit aktiviert, so dass eine Anwendung eine Programmdatei (.prg) erzeugen und kompilieren kann. Mit Hilfe der STRTOFILE( )-Funktion können Sie Code in eine Programmdatei ausgeben. Die Kompilierung zur Laufzeit funktioniert nun für alle Dateien, die von dem COMPILE-Befehl unterstützt werden, einschließlich Programmen, Formularen, Klassen, Berichten und Datenbanken.

Zwischen dem Compiler in der Entwicklungsumgebung und dem Compiler in der Laufzeitumgebung gibt es einige Unterschiede:

• Die Option ? des COMPILE-Befehls wurde für die Laufzeitumgebung deaktiviert, da unbeaufsichtigte Automatisierungsserver (.dlls) keinen Modus zulassen, der Benutzereingaben einbezieht.
  
• Der SET DEVELOPMENT-Befehl hat zur Laufzeit keine Wirkung.
  
• Bei einer vollständigen Produktinstallation führt die Verwendung von SET DEVELOPMENT dazu, dass Visual FoxPro bei Ausführung eines Programms Erstellungsdatum und -Uhrzeit des Programms mit den entsprechenden Angaben der kompilierten Objektdatei vergleicht. Wenn SET DEVELOPMENT auf ON festgelegt ist, wird immer die aktuelle Version ausgeführt, und veraltete Programme werden automatisch neu kompiliert. Zur Laufzeit muss der COMPILE-Befehl explizit aufgerufen werden, um den Quellcode neu zu kompilieren. Dies bedeutet, dass der Aufruf des DO-Befehls zur Laufzeit nie zur Folge hat, dass die .prg-Datei neu kompiliert wird. Zur Laufzeit berücksichtigt der DO-Befehl zudem keine Dateierweiterungen und sucht deshalb auch dann nach einer Datei mit der Erweiterung .fxp, wenn Sie .prg angeben.
  
• Durch diese Verfügbarkeit des COMPILE-Befehls zur Laufzeit ist es jetzt möglich, Quellcode zur Laufzeit zur kompilieren und damit auf Runcodeinterpreter, die ein doch wesentlich langsameres Laufzeitverhalten hatten, zu verzichten. Sie können jetzt erheblich flexiblere Programme schreiben. Beispiele dafür sind z.B:
1. Plausibilitäten, die einfach geändert werden können.
2. Berechnungen, die in Abhängigkeit von den zu verabeitenden Daten stehen.
3. Bereitstellung von unterschiedlichen Daten zur Laufzeit.

Bisher mußten Sie diese Funktionalitäten komplett im Quellcode hinterlegen. Jetzt ist es möglich, durch Speichern dieser Codesnippets in einem Memofeld einer Tabelle auf einfache Art den Code zu verändern, ohne dass die Anwendungn verändert bzw. neu kompiliert werden muß.

EditBox: AddLineFeeds-Eigenschaft

Diese Eigenschaft legt fest, dass innerhalb des Textes eines Editbox-Steuerelementes Zeilenvorschubzeichen (CHR(10)) nach Wagenrücklaufzeichen (CHR(13)) eingefügt werden sollen, sobald die Value-Eigenschaft gelesen oder der Wert in ControlSource gespeichert wird. Die Eigenschaft ist zur Entwurfs- und zur Laufzeit verfügbar.

Syntax
Object.AddLineFeeds[ = lExpr]

 

LExpr-Wert	Beschreibung
Wahr (.T.) (Standard)	Innerhalb des Textes eines Bearbeitungsfeld-Steuerelements werden Zeilenvorschubzeichen (CHR(10)) nach Wagenrücklaufzeichen (CHR(13)) eingefügt, sobald die Value-Eigenschaft gelesen oder der Wert in ControlSource gespeichert wird
Falsch (.F.)	Der Text des Bearbeitungsfeld-Steuerelements wird nicht geändert, wenn die Value-Eigenschaft gelesen oder in ControlSource gespeichert wird

BUILD MTDLL-Befehl

Dieser Befehl erstellt mit Hilfe von Klasseninformationen aus einer Projektdatei eine Multithread-DLL (Dynamic Link Library) mit der Dateinamenerweiterung .dll.

Syntax
BUILD MTDLL MTDLLFileName FROM ProjectName [RECOMPILE]

 

Argument	Beschreibung
MTDLLFileName	Gibt den Dateinamen der zu erstellenden DLL an. Die Standard-Dateinamenerweiterung ist .dll
ProjectName	Gibt den Namen des Projekts an, auf dessen Basis die DLL erstellt wird. Das Projekt muss eine Klasse enthalten, die als OLEPUBLIC festgelegt ist; andernfalls wird eine Fehlermeldung angezeigt. Um eine Klasse im Programmcode als OLEPUBLIC festzulegen, müssen Sie das OLEPUBLIC-Schlüsselwort in DEFINE CLASS einbeziehen. Um eine Klasse im Klassen-Designer als OLEPUBLIC festzulegen, müssen Sie im Menü Klasse den Befehl Klasseninfo auswählen und das Kontrollkästchen OLE Public aktivieren
RECOMPILE	Gibt an, dass das Projekt neu kompiliert wird, bevor die DLL erstellt wird. Alle Programm- und Formatdateien, der Quellcode für Formulare, Bezeichnungen, Berichte und Bibliotheken visueller Klassen sowie gespeicherte Prozeduren in Datenbanken, die in dem Projekt enthalten sind, werden kompiliert

Diese Funktionalität wird auch über das Menü Projekt im Dialogfeld Erstellungsoptionen bereitgestellt.

Session-Klasse

Diese Klasse erstellt ein benutzerdefiniertes Objekt, das seine eigene Datensitzung verwaltet. Damit ist es möglich, einer Containerklasse eine eigene (private) Datensitzung zu ermöglichen.

Syntax
DEFINE CLASS ClassName1 AS Session

Sie können diese benutzerdefinierte Klasse nur mit dem DEFINE CLASS-Befehl erstellen. Sie können dieses Objekt jedoch programmgesteuert zu einem Formular oder einem anderen Container hinzufügen.

DataSession-Eigenschaft

Diese Eigenschaft gibt an, ob ein Objekt in seiner eigenen Datensitzung (mit einer eindeutigen Datenumgebung) ausgeführt wird. Die Eigenschaft ist zur Entwurfszeit verfügbar; zur Laufzeit ist sie schreibgeschützt.

Syntax
Object.DataSession[ = nSession]

Einstellungen
nSession (1 à Standardsitzung, 2 à Private Datensitzung (Default))

DataSessionID-Eigenschaft

Diese Eigenschaft gibt die Datensitzungs-ID zurück, die die private Datensitzung für das Objekt kennzeichnet. Die Eigenschaft ist zur Entwurfszeit schreibgeschützt; zur Laufzeit kann sie gelesen und eingestellt werden.

Syntax
Object.DataSessionID

Hinweise

Die Standardeinstellung für DataSession ist 2 (privat), wodurch sie sich von den Klassen Form, Formset und Toolbar unterscheidet, die standardmäßig den Wert 1 aufweisen.

_VFP-Systemvariable

Diese Systemvariable wurde um Eigenschaften erweitert, die mit den Erweiterungen für Multithread-Automatisierungsserver zusammen hängen.

ThreadID-Eigenschaft

Diese Eigenschaft gibt die Win32-ID des Threads zurück, in dem das Objekt aufgerufen wurde.

Syntax
_VFP.ThreadID

ProcessID-Eigenschaft

Diese Eigenschaft gibt den eindeutigen Bezeichner des aktuellen Prozesses zurück.

Syntax
_VFP.ProcessID

Die Eigenschaft _VFP.StartMode wurde um die Option 5 erweitert, die anzeigt, das Visual FoxPro als prozessinterner multithreadfähiger .dll-Automatisierungsserver gestartet wurde.

Project/ ProjectHook

Die Build-Methode des Project-Objekts und das ProjectHook BeforeBuild-Ereignis wurde erweitert, so dass sie nun die neue Option 5 für den Multithread-Server umfassen.

Visual FoxPro-Laufzeitbibliotheken

Visual FoxPro 6 SP3 wird jetzt mit zwei separaten Laufzeitbibliotheken ausgeliefert:

• VFP6R.DLL Die Standardlaufzeitbibliothek für die meisten Anwendungstypen. Dies ist die bisher standardmäßige Laufzeitbibliothek von Visual FoxPro.
  
• VFP6T.DLLDie Besondere Multithread-Laufzeitbibliothek für extrem skalierbare prozessinterne Serveranwendungen, z.B. Anwendungen, die für die Verwendung mit Microsoft Transaction Server erstellt werden

Wenn Sie das Dialogfeld Erstellungsoptionen des Projekt-Managers verwenden, wird durch die von Ihnen ausgewählte Erstellungsaktion festgelegt, welche Laufzeitbibliothek von der erstellten Anwendung oder dem erstellten Server verwendet wird. Nur .dll-Server können die Laufzeitbibliothek Vfp6t.dll verwenden. Die Project.Build-Methode ermöglicht Ihnen ebenfalls, die zu verwendende Laufzeitbibliothek auszuwählen.

Der kompilierte Quellcode (z.B. eine .exe- oder .dll-Datei) wird intern gekennzeichnet, um anzuzeigen, welche Laufzeitbibliothek bei einem Aufruf verwendet werden soll. Die einzige Möglichkeit, die von einem Server verwendete Laufzeitbibliothek zu ändern, besteht darin, den Server neu zu erstellen. Mit Hilfe der schreibgeschützten Application.StartMode-Eigenschaft kann der Server zur Laufzeit ermitteln, welche Laufzeitbibliothek er verwendet. Sie müssen wissen, welche Laufzeitbibliothek Ihrem .dll-Server zugeordnet ist, um die einzubindende Laufzeitbibliothek im Setup-Assistenten richtig auswählen zu können.

Anmerkung Wie die anderen Visual FoxPro-Laufzeitdateien werden auch diese Dateien im Systemordner von Windows installiert. Beide Laufzeitbibliotheken verwenden dieselbe Ressourcendatei (z.B. vfp6renu.dll). Nur die Bibliothek Vfp6r.dll unterstützt die Selbstregistrierung (über regsvr32.exe), dies ist nur für Active Documents, jedoch nicht für COM-Server erforderlich. Der Setup-Assistent nimmt die Registrierung dieser Laufzeitbibliothek für Sie vor.

Die Laufzeitbibliothek Vfp6r.dll unterstützt den gesamten Sprachsatz von Objekten, Befehlen und Funktionen.

Um mit Vfp6t.dll eine auf Wesentliches reduzierte Laufzeitbibliothek für prozessinterne Server bereitstellen zu können, wurden viele Befehle und Funktionen, die von Benutzereingaben abhängen, entfernt. Die gesamte Objektsyntax ist weiterhin verfügbar, allerdings wurden die Ereignisse visueller Klassen, z.B. von Formularen, deaktiviert. Zusätzlich wurden die folgenden Sprachkategorien aus Vfp6t.dll entfernt:

• READ, @…Get/Says
  
• Menü-, Popupmenü- und Befehlsleistenbefehle und Funktionen
  
• MESSAGEBOX() und WAIT WINDOW
  
• Befehle und Funktionen für benutzerdefinierte Fenster

Welche Laufzeitbibliothek Sie verwenden, hängt von mehreren Faktoren ab, z.B. davon, wie die Serveranwendung bereitgestellt und wie sie verwendet wird.

Erweiterungen an COM-Komponenten

Visual FoxPro ermöglicht Ihnen seit der Version 5 die Erstellung von Automatisierungsservern (auch als COM-Komponenten bezeichnet). Damit können Sie entweder einen prozessexternen oder einen prozessinternen Automatisierungsserver erstellen. Ein Automatisierungsserver ist eine Anwendung, die Funktionalität bereitstellt, die mit Hilfe der Automatisierung von anderen Anwendungen verwendet oder wieder verwendet werden kann.

Prozessexterne Server (.exe)

Ein prozessexterner Automatisierungsserver (.exe) kann über eine Benutzeroberfläche verfügen. Die Funktion SYS(2335) ermöglicht es Ihnen, Ereignisse der Benutzeroberfläche und modale Ereignisse für einen prozessexternen .exe-Automatisierungsserver zu deaktivieren, so dass die Remoteverarbeitung ohne Benutzerintervention möglich ist. Modale Ereignisse werden von benutzerdefinierten, modalen Formularen, Systemdialogfeldern, der MESSAGEBOX( )-Funktion und dem WAIT-Befehl usw. erstellt und erfordern normalerweise eine Benutzereingabe. Beispiel wäre die Anzeige eines wieder verwendbaren Formulars.

Prozessinterne Server (.dll)

Für die Unterstützung des Apartmentmodell-Threadings dürfen prozessinterne .dll-Automatisierungsserver keine Benutzeroberfläche verwenden. Wenn Sie in Visual FoxPro 6.0 und Visual FoxPro 6 SP3 versuchen, eine Benutzeroberfläche in einer prozessinternen DLL zu erstellen, löst dies einen Fehler aus. Dies wird als unbeaufsichtigter Modus bezeichnet. Sie könnten z. B. eine oder mehrere Klassen erstellen, um unternehmensweit gültige Geschäftsregeln zu verwalten. Eine Clientanwendung, die das COM-Objekt verwendet, würde Eingabeparameter in einem Methodenaufruf übergeben, und der Automatisierungsserver könnte dann umfangreiche Operationen durchführen, z.B. Abrufen oder Speichern von Daten aus unterschiedlichen Quellen und Durchführen komplexer Berechnungen, bevor die Antwort zurückgegeben wird.

Singlethread-Objekte

Wenn eine COM-Komponente über einen einzigen Ausführungsthread verfügt, kann zu einem bestimmten Zeitpunkt der Code für nur ein Objekt ausgeführt werden, d.h. die Anforderungen werden in eine Warteschlange eingereiht und nacheinander verarbeitet, bis alle Anforderungen abgeschlossen wurden.

In einer Multithread-Betriebsumgebung schützt diese Eigenschaft Singlethread-Objekte vor überlagernden Clientanforderungen, d.h. vor Code in einer Eigenschaft oder Methode, der ausgeführt wird, während eine oder mehrere frühere Clientanforderungen noch ausgeführt werden. Überlagernde Anforderungen können zu internen Datenfehlern führen, wenn Objekte nicht reentrantfähig sind.

Problem

Nehmen Sie z.B. an, Sie verwenden ein Daten-Objekt, das über zwei Methoden verfügt: GetDataAll und GetDataOne

• Die GetDataAll-Methode benötigt für die vollständige Ausführung einen Zeitraum, der von einigen Sekunden bis zu einer halben Stunde dauern kann.
• Die GetDataOne-Methode ist nahezu augenblicklich beendet.

Da Multithread-Betriebsumgebungen über präemptives Multitasking verfügen, könnte eine zweite Anwendung die GetDataOne-Methode aufrufen, während die GetDataAll -Methode bereits ausgeführt wird. Die kurze GetDataOne-Methode muss solange warten, bis die lange GetDataAll -Methode vollständig ausgeführt wurde.

Multithread-Objekte

Die Multithread-Laufzeitbibliothek in Visual FoxPro 6 SP3 ermöglicht eine deutlich verbesserte Skalierbarkeit prozessinterner Automatisierungsserver.

Auf einem Computer mit nur einem Prozessor führt die Verwendung von Multithreading beispielsweise bei einer Mischung aus langen und kurzen Tasks zu einer wahrnehmbaren Leistungsverbesserung. Multithread-Methodenaufrufe können jedoch mitunter mehr Zeit in Anspruch nehmen als Singlethread-Methodenaufrufe. Die Verwendung des Multithreadings bringt dann große Vorteile mit sich, wenn die meisten Threads einen Großteil der Zeit blockiert sind, um z.B. auf Datei-E/A zu warten, so dass andere Threads Code zu jedem beliebigen Zeitpunkt ausführen können.

Nehmen Sie z.B. an, die Methoden A und B werden gleichzeitig aufgerufen. In einer Single-Thread-Komponente werden die Anforderungen serialisiert, so dass B erst dann beginnt, wenn A beendet wurde. Verwenden Sie hingegen Multithreading, "wetteifern" die beiden aktiven Threads um die Prozessorzeit.

Dies führt nicht nur zu einer wahrnehmbaren Erhöhung der durchschnittlichen Beendigungszeit, sondern es wird zudem auch mehr Prozessorzeit für das Hin- und Herwechseln zwischen den Threads benötigt. Das Problem ist, dass die Ausführung von Methode A und Methode B ungefähr den gleichen Zeitaufwand benötigt.

Wenn Methode B z.B. nur drei Zeitabschnitte für die Beendigung benötigte, würde der Benutzer des Systems eine beträchtliche Verbesserung der Reaktionsgeschwindigkeit von Methode B und nur eine geringfügige Verlängerung der für Methode A benötigten Ausführungszeit wahrnehmen.

Wenn Sie eine Anwendung entwerfen, die auf einem Computer mit einem Prozessor ausgeführt werden soll und die sich durch Threadblockierung in geringem Umfang auszeichnet, sollten Sie die Verwendung der Laufzeitbibliothek Vfp6r.dll erwägen. Auf Multiprozessorcomputern und für die meisten anderen Einsatzgebiete empfiehlt sich hingegen die Verwendung von Vfp6t.dll für .dll-Server.

Update der FoxISAPI-Unterstützung

Die Datei foxisapi.dll wurde aktualisiert, um neue prozessinterne Multithreadserver zu unterstützen. Für MTDLL-Server muss die Pool Manager-Unterstützung in der Datei foxisapi.ini deaktiviert werden. 

Wenn Sie FoxISAPI mit prozessinternen Multithreadservern von Visual FoxPro 6 SP3 verwenden, müssen Sie die Pool Manager-Unterstützung in FoxISAPI deaktivieren. Verwenden Sie hierzu die PoolMode-Einstellung in der Datei Foxisapi.ini (durch Festlegen auf 0). Die PoolMode-Einstellung gilt für alle Server; es wird deshalb empfohlen, nicht nur eine Kopie von Foxisapi.dll sowohl für EXE- als auch für DLL-Server zu verwenden. Stattdessen sollten Sie die Dateien Foxisapi.dll und Foxisapi.ini kopieren und umbenennen, so dass Ihnen ein Satz dieser Dateien für EXE-Server und ein Satz für DLL-Server zur Verfügung steht.

Behandlung allgemeiner Schutzverletzungen

In den früheren Versionen von Visual FoxPro führte eine allgemeine Schutzverletzung oder ein fataler Fehler zur Anzeige eines von zwei Dialogfeldern. Angezeigt wurde entweder ein Dr. Watson-Dialogfeld oder ein Dialogfeld, das angab, dass eine allgemeine Schutzverletzung aufgetreten war. Wenn in Visual FoxPro 6.0 eine allgemeine Schutzverletzung oder ein fataler Fehler auftritt und eine xBase-Aufrufliste verfügbar ist, wird ein Dialogfeld angezeigt, das die Programmaufrufliste angibt. Mit den Informationen zur Aufrufliste können Sie den problematischen Code leichter verfolgen als in früheren Versionen. Wenn keine Aufrufliste verfügbar ist, wird eine Fehlermeldung mit einem Text wie "Schwerer Fehler: Ausnahmecode=C0000005" ausgegeben und Visual FoxPro beendet.

In Visual FoxPro 6.0 SP3 wurde dieses Verhalten für die Situationen geändert, in denen keine Xbase-Aufrufliste verfügbar ist (z.B. in Laufzeitanwendungen zum Vertrieb). Wenn eine allgemeine Schutzverletzung auftritt und keine Aufrufliste verfügbar ist, entspricht das Ergebnis dem Verhalten in Versionen vor Visual FoxPro 6.0 (Dr. Watson oder Abbruch/Debuggen, je nachdem, welche Reaktion registriert wurde). Wie in Visual FoxPro 6.0 können die Benutzer die Ausgabe dieses Fehlers deaktivieren, indem sie den folgenden Registrierungsschlüssel mit dem Zeichenfolgenwert "0" hinzufügen:

HKEY_CLASSES_ROOT\VisualFoxpro.6\Exceptions

Beseitigte Bugs

Einer der Schwerpunkte des Service-Packs 3 in der Fehlerbereinigung war die Beseitigung der beliebten C000005 Fehlern, die zum Absturz von Visual FoxPro führten. So wurden mit dem SP3 ca. 200 Bugs beseitigt, wovon viele den o.g. Fehler verursachten.

Nachfolgend werden hier einige interessante Bugs dargestellt, die einigen von Ihnen sicherlich schon einiges Kopfzerbrechen bereitet haben, jetzt aber beseitigt sind:

• In Visual FoxPro wird der Activate()-Event der Page nicht über die Tastatur ausgelöst
In Visual FoxPro vor SP3 wurde der Activate()-Event der Page nicht ausgelöst, wenn die Page über die Tastatur angewählt wird. Über die Maus wird der Activate()-Event ausgelöst.

• Schlechte Leistung bei Formularen, die viele Objekte enthalten. Wenn eine Form oder ein Container instanziiert wird, der viele Objekte enthält, ist ein sehr schlechtes Laufzeitverhalten festzustellen. Das gleiche Verhalten ist auch bei einem Pageframe mit vielen Pages festzustellen.
 
• Ein Formularobjekt wird nach der Verwendung von PEMSTATUS() nicht freigegeben. Nach Aufruf der PEMSTATUS()-Funktion in einer Form kann das Formobjekt nicht über den Close button freigegeben werden. Auch ein _Screen.ActiveForm.Release Kommando gibt das Formobjekt nicht frei.
 
• C0000005 Schwerwiegender Fehler bei ungültigen Eigenschaftennamen. Wenn Sie eine Eigenschaft eines Objects innerhalb einer Methode ansprechen, die nicht existiert, beendet sich Visual FoxPro mit c000005
 
• Eine mehrfach geöffnete Memodatei kann zu Fehlern führen. Wenn eine Tabelle in einer Multiuser-Umgebung von einem Client geöffnet wird und die Memodatei lockt, öffnet ein zweiter Client die Memodatei mit einer falschen Blockgröße. Dies kann dazu führen, daß beim zurückschreiben in dieses Memofeld die Memodatei korrupt wird oder falsche Feldinhalte zurückgibt.
 
• Der Click-Event eines Containers feuert nicht, wenn auf ein deaktiviertes Steuerelement geklickt wird. Der Click-Event eines Containers feuert nicht, wenn auf ein deaktiviertes Steuerelement geklickt wird, welches sich innerhalb eines Containers oder eines Pageframes befindet. Stattdessen wird der Click-Event des Formulars ausgeführt.
 
• C0000005 Schwerwiegender Fehler mit ISBLANK( ) und Array-Eigenschaft im Init. Wenn Sie im Init-Event einer Form, die programmatisch erstellt wurde, die ISBLANK()-Funktion mit einem Arrayelement benutzen, stürzt Visual FoxPro mit C0000005 ab. Handelt es sich um eine Form, die mit dem Formulardesigner erstellt wurde, erscheint kein Fehler, aber die Show-Methode der Form wird nicht ausgeführt, so dass die Form nur kurz erscheint und dann gleich wieder verschwindet.
 
• C0000005 Schwerwiegender Fehler bei TRANSFORM() mit langen Zeichenfolgen. Bei Benutzung der TRANSFORM()-Funktion mit Zeichenfolgen größer als 255 Zeichen, stürzt Visual FoxPro sporadisch ab.
 
• Leistungsabfall bei wiederholten SQL SELECTs. Bei wiederholten Aufrufen von SQL SELECT-Befehlen, die die WHERE und die OR Klausel enthalten ist eine Veschlechterung des Laufzeitverhaltens festzustellen.

Noch nicht beseitigte Bugs

Natürlich konnte auch das Visual FoxPro Service-Pack 3 noch nicht alle Probleme beseitigen. Hier sind zwei Beispiele aus eigener Erfahrung.

• Visual FoxPro stürzt in der Entwicklungsumgebung sporadisch nach der Anlage einer neuen Eigenschaft oder Methode für eine Klasse oder Form ab. Dieser Fehler tritt nur sporadisch auf, aber natürlich immer dann, wenn man mindestens 300 Zeilen Quellcode in den Methoden dieser Klasse/Form noch nicht gespeichert hat.
• Intensives arbeiten mit einer Editbox, bei der Cut and Paste Operationen mit großeren Datenmengen durchgeführt werden, erzeugen einen c0000005-Fehler.

Zusammenfassung

Das Service Pack 3 für Visual FoxPro sollten Sie auf jeden Fall installieren. Es sorgt für eine größere Stabilität des Fuches und bietet gerade in der Entwicklung von COM-Komponenten neue Möglichkeiten.

Vergessen Sie bitte auch nicht, daß Sie Ihren Kunden eine neue Runtime-Version von Visual FoxPro zukommen lassen !

Für Fragen stehe ich Ihnen jederzeit unter Flohr@indisoftware.de zur Verfügung.

Sie erreichen mich auch im dFPUG-Forum auf Compuserve unter CIS 106205,3221 oder auf unserer Website www.indisoftware.de.