Foxpro and beyond

Datenaustausch VFP <-> .NET

2010-07-13T22:00:00.006+02:00

Nach diversen Exprimenten haben wir uns entschieden, zwei Verfahren zu betreiben:

a) Einen Datensatz zum Bearbeiten holen.

Lesen: Dazu wird VFP angewiesen den aktuellen Datensatz einer View in eine DBF im Temp-Ordner zu kopieren.
Danach liest .NET über den VFPOleDB-Treiber und den OleDBReader die DBF in eine DataTable. Das Businessobjekt VFPRecordBase belädt aus dieser seine Properties.
Schreiben: Das BO genieriert aufgrund der geänderten Properties einen SQL-UPDATE-Befehl und schickt diesen an VFP. Analog wird beim Löschen und Anlegen verfahren.

b) Einen Cursor zur Anzeige holen

Dazu formuliert das BO auf Basis seiner Properies ein SQL SELECT, das an VFP geschicht wird.
Danach liest .NET über den VFPOleDB-Treiber und den OleDBReader die DBF in eine DataTable. Das Businessobjekt vom Typ List<VFPRecordBase> legt eine Liste an und befüllt diese mit VFPRecordBase-Objekten.

Vorteil: keine weitere Installation/Administration von Komponenten (Webserver)
Nachteil: wg. COM-Kopplung ist die .NET-Seite auf 32 Bit festgelegt.

Das ganze Konstrukt ist weiterhin für den Desktop gedacht.
Es sollte jedoch möglich sein, auf .Net-Seite einen Webservice anzubieten. Damit könnte das Konstrukt auf einem Server laufen (in 32 Bit), der Client (Konsument des Webservice über WCF) ist aber unabhängig: 64 Bit, Silverlight, im Browser oder außerhalb, alles geht.

Dem Cloud-Computing steht damit nichts mehr im Wege. Aber das ist eine ganz andere Baustelle.
Obwohl: Microsoft pusht das ganze jetzt über seine Azure-Plattform...

Rettung in Sicht

2010-07-04T17:10:00.000+02:00

Trotz der Hitze haben wir unsere Köpfe rauchen lassen. Das Ergebnis ist vielversprechend!

Es ist tatsächlich möglich, Foxpro auf zwei Weisen zu nutzen:

als passiver Daten-Lieferant: hier läuft VFP als COM-Server und liefert der .Net-GUI auf deren Wunsch als COM-Client die Anzeige-Daten.
als aktiver Teil, der Dienste der GUI verwenden kann (z.B. MessageBoxen oder Fortschrittsbalken). Hier wird von VFP eine dritten Komponente verwendet: die VFPBridge. Diese stellt Dienste bereit, z.B. ShowMessagebox(). Die Gui sieht die VFPBridge über dei VFP-Instanz und kann damit Ereignisse der VFPBridge abonnieren, die von den Dienste-Methoden der VFPBridge ausgelöst werden.

Wie man sieht, sind die Details des Verfahrens relativ kompliziert. Dennoch ist damit die grundlegende Aufgabe des Datenaustauschs in beide Richtungen zwischen VFP und .NET elegant und ohne irgendwelche Hilfskonstrukte wie Polling oder Steuerdateien gelöst.
Eine Veröffentlichung hier ist aktuell nicht geplant. Interessenten können sich jedoch gerne melden.

Nächstes Thema ist, wie möglichst einfach und typsicher der Austausch einzelner Datensätze oder Cursordateien abzuwickeln ist.

Wie weiter mit Foxpro?

2010-06-04T21:14:00.000+02:00

Kein Zweifel, die Zeit von Visual Foxpro neigt sich dem Ende zu. Das Produkt wird nicht mehr weiterentwicklet, es wird niemals eine 64 Bit-Version geben.
Zugegeben, das ist ein Luxusproblem, denn 32-Bit-Anwendungen werden noch lange Zeit laufen. Allergings laufen 16-Bit-Anwendungen in 64-Bit-Umgebungen schon heute nicht mehr. Was also, wenn irgendwann mal 128-Betriebssysteme erscheinen? Richtig, der 32bittige Fuchs wirds nicht überleben.

Andererseits: der Fux ist immer noch produktiver als selbst das aktuelle .Net FW 4.0. Es existiert eine riesige Codebasis. Diesen Code kann man nicht mit wirtschaflich vertretbarem Aufwand migrieren.

Was sind die Optionen?

Microsofts aktuelle GUI-Technologie heißt WPF bzw. Silverlight. Die Masken werden in XAML beschrieben, was bedeuted, dass Foxpro-Masken konvertiert werden können. Foxpro kann als COM-Server die Daten liefern. Und , Voila! habe ich eine zeitgemäße GUI und die vielen Mannjahre Investition in Logik und Datenschicht sind gerettet.

Fortsetzung folgt...