Navigation


German VFPConversion Developer's Blog

Dieser Blog ist allen VFP-Entwicklern gewidmet, die .NET und SQL Server in Ihren Applikationen einsetzen oder komplett darauf umsteigen wollen. Das inkludiert natuerlich auch .NET 3.0 Technologien wie WPF und WCF.

Content Area Footer

Thursday, August 23, 2007
Calvin Hsia's coole LINQ Beispiele (mit VFP Vergleich)

Calvin Hsia (frueherer Lead Developer des Microsoft VFP Teams) hat auf seinem Blog einige LINQ Beispiele veroeffentlicht die zum einen einige coole LINQ Features zeigen, und zum anderen auch LINQ mit VFP Datenabfragen vergleichen. Zu sehen sind diese Beispiele hier und hier.



Posted @ 2:59 PM by Egger, Markus (markus@code-magazine.com) -
Comments (19)


Monday, July 02, 2007
Hosting the .NET Runtime in Visual FoxPro

Rick Strahl hat einen interessanten Post ueber das Hosten der .NET Runtime in VFP. Naeheres dazu hier.



Posted @ 1:52 PM by Egger, Markus (markus@code-magazine.com) -
Comments (19)


Wednesday, June 20, 2007
VFP Forms und Windows Vista Aero

Eine der wichtigen Neuerungen in Windows Vista ist der "Aero Glass" Grafikstil, der halbtransparente Window Titel sowie die 3D Darstellung von Fenstern und andere aehnliche Dinge ermoeglicht. Leider funktioniert dieser Stil mit VFP nicht, wenn der Anwender nicht als Administrator eingeloggt ist (was in Vista normalerweise nicht der Fall ist). Das bedeutet das VFP Fenster in der Vista-Standardkonfiguration nicht funktionieren.

Wie sich herausstellt ist das Problem darin begruendet dass VFP Fenster zuerst als Standardfenster erstellt, und dann weitere Einstellungen vornimmt, wie z.B. den Rahmenstil zu setzen. Dies ist in dieser Reihenfolge in Vista jedoch inkorrekt. Gluecklicherweise kann man dieses Problem manuell beheben.

Calvin Hsia beschreibt in einem seiner Blog Posts wie man dieses Problem im Detail beheben kann.



Posted @ 9:28 PM by Egger, Markus (markus@code-magazine.com) -
Comments (6)


Sunday, June 17, 2007
Applikationsinstallation: Einfacher mit .NET oder VFP?

Vor allem auf englischen Blogs ist in letzter Zeit die Frage zirkuliert, ob es einfacher sei VFP oder .NET Applikationen zu installieren.

Grundsaetzlich ueberraschen mich derartige Fragen nicht, schliesslich ist es recht ueblich dass VFP Entwickler spezifische Features (z.B. individuele Befehle) der beiden Systeme miteinander vergleichen. Aber beim Thema "Installation" scheint der Vergleich doch etwas zu hinken, speziell weil einige Blogger sogar der Meinung zu sein scheinen, .NET Applikationsinstallationen seien kompliziert...

Um etwas Klarheit in die Angelegenheit zu bringen: Installationen koennten kaum einfacher sein als dies in .NET der Fall ist.

Eine typische .NET Installation kann einfach dadurch vorgenommen werden dass die Applikationsdateien von einer Maschine zur anderen kopiert werden. Voila! So einfach kann's sein. Natuerlich ist das fuer eine professionelle Applikation nicht sonderlich attraktiv. Deshalb gibt es in .NET auch seit je her die Moeglichkeit "Setup Projekte" zu erstellen. Das kann man sich aehnlich vorstellen wie der VFP Installation Wizard, nur dass es sich in .NET um ein standard .NET Projekt handelt, dass auch mit standard .NET Code erweitert werden kann. Der ganze Vorgang ist sehr einfach: Man fuegt einfach die EXE der Applikation die installiert werden soll dem Projekt zu, und alle "Dependencies" werden automatisch ins Projekt mit aufgenommen und koennen dann dort sehr einfach verwaltet werden.

Es ist natuerlich auch moeglich .NET Applikationen automatisch zu updaten. Mit standard Windows Setups kann sowas ueber den sogenannten "application deployment block" realisiert werden. Noch einfacher geht's ueber ClickOnce. Diese Technologie hat sich mittlerweile wunderbar in der Praxis etabliert. Anfaengliche Sorgen dass ClickOnce eine reine "Demo Technologie" waere haben sich somit als nichtig herausgestellt. Wer ClickOnce gerne in Action sehen moechte kann sich Xiine ansehen (hierbei handelt es sich um unsere neue Verlagssoftware, die es ermoeglicht Artikel und Buecher - unter anderem auch VFPConversion.com Whitepapers - in einer digitalen Technologie der naechsten Generation zu lesen). Den Gratisdownload gibts auf www.Xiine.com.

Natuerlich kann man mit .NET viel mehr machen als nur Windows Applikationen. Die oben genannten Technologien decken aber das Setup-Spektrum ab. Sogar Spezialapplikationen wie Windows Services oder DirectX Applikationen (beides wird ja in VFP nicht direkt unterstuetzt und ein Vergleich ist daher schwierig...) koennen mit diesen Technologien problemlos installiert werden...



Posted @ 2:21 PM by Egger, Markus (markus@code-magazine.com) -
Comments (5)


Thursday, January 25, 2007
Neue CoDe Focus Ausgabe: VFP 'Sedna'

In wenigen Wochen erscheint eine neue CoDe Focus Ausgabe (eine Specialausgabe des CoDe Magazine) fuer VFP. Der Titel der englischen Publikation ist "Sedna: Beyond VFP 9".

Dieses Magazin kann voellig kostenlos bezogen werden. Sie muessen sich lediglich unter folgender URL anmelden und ankreuzen dass sie sich fuer Visual FoxPro interessieren:

http://www.code-magazine.com/focus/interests.aspx

Vie Spass! (Dieser Link kann ruhig weitergegeben werden...)

Anmerkung: Wir planen weitere Sonderausgaben fuer die naechsten Monate die unterschiedliche Themen behandeln. Auch dafuer koennen Sie sich auf der selben URL anmelden...



Posted @ 4:34 PM by Egger, Markus (markus@code-magazine.com) -
Comments (71)


Sunday, December 10, 2006
EPS MVPs...

Microsoft hat unlaengst die MVP Awards fuer 2007 vergeben. Auch diees Jahr sind einige davon an EPS und unsere Partner gegangen.

Eine detailierte Liste gibt's hier.



Posted @ 12:23 PM by Egger, Markus (markus@code-magazine.com) -
Comments (9)


Monday, November 13, 2006
PodCast von Dr. Neil's Interview mit Markus

Letzte Woche wurde ich von Dr. Neil fuer seinen PodCast interviewed (aufgenommen auf der DevConnections Konferenz in Las Vegas). Dieses Interview ist jetzt online verfuegbar. Viel Spass!



Posted @ 2:22 PM by Egger, Markus (markus@code-magazine.com) -
Comments (4)


Tuesday, November 07, 2006
Top-News: Neue Microsoft Produkte

Mit TechEd Europe und DevConnections 2006 in Las Vegas (die Konferenz auf der ich als Sprecher taetig bin) sind momentan 2 der wichtigsten Konferenzen in diesem Jahr in Gange. Microsoft hat diese Gelegenheit genutzt um verschiedenste Produkte entweder zu releasen, oder als Beta verfuegbar zu machen:

  • Office 2007 wurde gestern released
  • Visual Studio 2005 Tools for Office 2007 sind released
  • Das .NET Framework 3.0 (mit WPF, WCF und WF) wurde gestern released
  • Visual Studio 2005 extensions for .NET 3.0 ist jetzt verfuegbar (jedoch ohne die WPF Tools).
  • Internet Explorer 7 ist schon einige Tage verfuegbar.
  • Media Player 11 ist auch schon einige Tage verfuegbar

Mehr Informationen zu den Visual Studio Produkten gibts auf: http://msdn.microsoft.com/vstudio.

Ein wichtiges Produkt fehlt natuerlich auf dieser Liste: Windows Vista. Vista ist noch nicht released, aber es wuerde mich sehr ueberraschen wenn dies nicht auch in den naechsten Tagen geschehen wuerde.

Neben den fertigen Produkten gibt's auch noch einiges an neuen Betas: 

  • ASP.NET Ajax (beta 2)
  • Visual Studio 2005 SP1 (beta)
  • Expression Web Designer (beta 1 und nicht mehr CTP)
  • Exchange 2007 (beta 2)
  • SQL Server 2005 SP2 (beta) ist entweder bereits verfuegbar oder sollte in Kuerze verfuegbar sein
  • SQL Server Compact Edition (beta - ehemals "SQL Everywhere") ist entweder bereits verfuegbar oder sollte in Kuerze verfuegbar sein
  • Windows Live OneCare ist verfuegbar als beta
  • XNA Studio verfuegbar als beta

Und diese Liste ist wahrscheinlich nicht einmal vollstaendig (ich blogge zwischen Sessions und Meetings). Auch noch von Interesse: Eine neue Version von SharePoint ist im Anmarsch. Und auch die Betas des Expression Interactive Designer und des Expression Graphics Designer sollte es in nicht allzuferner Zukunft geben.
 



Posted @ 4:19 PM by Egger, Markus (markus@code-magazine.com) -
Comments (8)


Saturday, October 21, 2006
Stored Procs fuer Datenbanken ohne Stored Procs?

In meinem letzten Blog Post habe ich - fast nur nebenbei - angemerkt dass wir SQL Everywhere in Unit Test Szenarios anstatt SQL Server verwenden (zumindst in manchen Szenarios). Einer unserer Kunden hat mir zu diesem Thema eine gute Frage gestellt: Was machen wir in diesen Faellen mit Stored Procedures? Schliesslich unterstuetzt SQL Everywhere keine Stored Procedures.

Zu diesem Zweck haben wir ein spezielles System das wir "Stored Procedure Facade" nennen. Dieses System erlaubt es uns Stored Procedures zu simulieren, so dass der Rest der Applikation den Unterschied nie zu sehen bekommt. Die Stored Procedure Facade ist Teil unserer Milos Solution Platform. Mein Artikel in der letzten CoDe Focus Tablet PC Ausgabe beschreibt wie's geht (auch ohne Milos): http://www.code-magazine.com/Article.aspx?quickid=0512112

Apropos CoDe Focus: Wir arbeiten gerade an einer ganzen Reihe von neues Sonderausgaben (auch eine fuer VFP). Und wie immer sind diese Ausgaben voellig kostenlos. Wer sich dafuer interessiert sollte sich jetzt online anmelden.

 



Posted @ 5:13 PM by Egger, Markus (markus@code-magazine.com) -
Comments (8)


Sunday, August 06, 2006
SQL Everywhere

Die Microsoft SQL Server Familie erwardet Nachwuchs: SQL Server 2005 Everywhere Edition. Worum handelt es sich hier und warum braucht man diese neue Version von SQL Server?

SQL Server 2005 Evereywhere Edition (kurz "SQL Everywhere") ist eine kompakte Version von SQL Server die sich vor allem fuer Dinge wie automatisch installierte Smart-Client Applikationen eignet. Eine SQL Everywhere Datenbank ist eine einzelne SFD Datei die von der SQL Everywhere Engine verwaltet wird. Die Engine hat eigentlich mit der SQL Server Engine nichts zu tun und teilt sich nur den Namen. In Wirklichkeit handelt es sich hier um die SQL Server CE/ SQL Server Mobile Datenbankengine (die faelschlicherweise oft mit der Jet Engine verwechselt wird), die jetzt auf auf normalen Windows PCs zur Verfuegung steht.

Ein gravierender Unterschied zwischen SQL Everywhere und anderen SQL Server versionen (inklusive Express) ist dass SQL Everywhere extrem einfach zu installieren ist (einfach die SFD und DLL Dateien kopieren) und auch nicht als Service laeuft, sondern nur dann geladen wird wenn man tatsaechlich Datenbankfunktionalitaet verwendet. SQL Everywhere ist eigentlich nur eine weitere Komponente des .NET Frameworks und in der Handhabung und Installation ident zu anderen .NET Framework Komponenten.

Der eigentliche Datenbankzugriff ist dem von SQL Server sehr aehnlich. Man verwendet lediglich eine SqlCeConnection Objekt, anstatt der normalen SqlConnection. Man verwendet auch ein SqlCeCommand Objekt und nicht SqlCommand, usw. Einziger grosser Unterschied hier ist das SQL Everywhere keine Stored Procedures unterstuetzt.

Fuer VFP Programmierer ist dieses Konzept natuerlich nicht drastisch neu. Schliesslich funktioniert dies alles aehnlich wie mit lokalen VFP DBF Dateien, mit dem kleinen Unterschied dass alle SQL Everywhere Tabellen in einer einzelnen Datei gespeichert werden koennen. Und natuerlich auch dass alle Datenbankoperationen ueber Objekte ablaufen und nicht ueber integrierte Befehle, was Architekturvorteile mit sich bringt (vor allem in den heute tyepischen Mehrschichtenapplicationen).

Somit gibt es jetzt folgende SQL Server Versionen:

  1. SQL Server (in verschiedenen Unterversionen, wie z.B. "Enterprise") - Ideal als "Workhorse" Datenbank in einem Client-Server Setup. Hier geht die Post ab. Diese Version ist dafuer geschaffen auch grosse Datenmengen verwalten zu koennen.
  2. SQL Server Express (frueher "MSDE") - Ideal fuer fortgeschrittene Datenbankanwendungen auf der lokalen Arbeitsstation. Die Installation ist dieser Version ist relativ einfach und auch ueber tools wie ClickOnce automatisiert. Allerdings braucht man entsprechende Admin Rechte um diese Version installieren zu koenne.
  3. SQL Server Everywhere - Ideal fuer Datenbanken die mit einzelnen Applicationen komplett transparent mitinstalliert werden muessen. Die Datenbankengine und die eigentlichen Datenbankdateien koennen einfach kopiert oder als Setupfiles installiert werden. Das funktioniert auch in "Partial Trust" Szenarien in denen man keine Admin Rechte hat.
  4. SQL Server Mobile (frueher "SQL CE") - Diese Version ist praktisch ident zu SQL Everywhere, ist jedoch darauf ausgelegt auf Windows Mobile Devices (Pocket PC, SmartPhone,...) zu laufen.

Eine Anwendung von SQL Everywhere die mir persoenlich sehr gut gefaellt: SQL Everywhere Datenbanken sind ideal fuer Unit Tests, da man die Datenbank einfach in das Unit Test Projekt einbinden kann. Dies eliminiert die externe Datenbankabhaengigkeit die Unit Tests oft schwierig gestalten kann.

Weitere Informationen zu SQL Everywhere gibt's auf dem Blog von Steve Lasker (einem der MS Product Managers) und auch in diesem Artikel.

PS: Unser hauseigenes Product "Milos Solution Platform" unterstuetzt SQL Everywhere seit der letzten Version direkt am Framework-Level. Die Einbinding ist voellig transparent und lediglich eine Konfigurationsoption. Wir hatten in diesem Zusammenhang auch bereits die Moeglichkeit SQL Everywhere zu testen und zu evaluieren, und koennen nur sagen "Hut ab!", diese Datenbank funktioniert hervorragend und ist sehr einfach anzuwenden. Natuerlich entspricht SQL Everywhere nach wie vor nicht dem "USE" Befehl von VFP, aber vor allem in Mehrschichtenszenarien muss man neidlos eingestehen das SQL Everywhere sehr gut funktioniert.

 

Posted @ 2:03 PM by Egger, Markus (markus@code-magazine.com) -
Comments (5)


Monday, April 24, 2006
Ein Paradebeispiel für die Verwendung von Generics

Die .NET Runtime 2.0 hat ein sehr tolles neues Feature mit dem Namen „Generics“. Generics haben viel mit Strong-Typing zu tun. Wie Sie vielleicht wissen, sollte alles, was man in .NET macht, strong-typed sein, da dies einen positiven Effekt auf die Qualität und vieler anderer Dinge in Ihrer Applikation hat. Jedoch gibt es einige Anwendungsgebiete, bei denen Strong Typing unter .NET 1.1 ignoriert werden musste bzw. musste der Entwickler alternativ eine Unmenge an Code schreiben, um die Vorteile von Strong Typing auch in diesen Fällen nutzen zu können.

Ein Beispiel ist eine Liste von Objekten, die in einer Collection gespeichert warden. Hierfür bietet .NET verschiedene Klassen, wie beispielsweise die ArrayList-Klasse. Eine Array-List kann alle Objekt-Typen speichern. Beispielsweise kann eine Array-List aus Forms bestehen:

ArrayList myForms = new ArrayList();
myForms.Add(new Form());
myForms.Add(new Form());
myForms.Add(new CustomerEditForm());

Dies ist C#-Code. Hätten Sie eine ArrayList-Klasse in VFP entworfen, würde das so aussehen:

LOCAL myForms
myForms = CreateObject("ArrayList")
myForms.Add(CreateObject("Form"))
myForms.Add(CreateObject("Form"))
myForms.Add(CreateObject("CustomerEditForm"))

Eine Collection von Objekten kann in vielen Fällen sehr praktisch sein, zum Beispiel kann man alle Forms in einer Collection in einer Schleife abfragen und am Bildschirm anzeigen:

foreach (Form frm in myForms)
{
    frm.Show();
}

Es gibt jedoch ein Problem, wenn jemand in der Collection etwas anderes als eine Form speichert, denn eine ArrayList kann ja wiegesagt alle Arten von Objekten speichern, nicht nur Forms. Der folgende Code würde also zu einer Katastrophe führen:

ArrayList myForms = new ArrayList();
myForms.Add(new Form());
myForms.Add(new Form());
myForms.Add(new Button());
foreach (Form frm in myForms)
{
    frm.Show();
}

Dieser Code würde zur Laufzeit einen Fehler verursachen, denn es gibt keine Möglichkeit, die ArrayList dahingehend zu überprüfen, ob sich nur Forms in der Auflistung befinden. Wie kann man dieses Problem also in den Griff bekommen? In .NET 1.1 löst man diese Aufgabenstellung, indem man eine Subklasse aus der ArrayList erstellt und eine Vielzahl von Eigenschaften und Methoden ändert (beispielsweise kontrolliert man in der Add()-Methode, ob es sich beim hinzuzufügenden Objekt auch um eine Form handelt). Das größte Problem bei dieser Vorgangsweise ist der große Zeitaufwand: Man muss eine Subklasse für Forms entwerfen, eine andere für Buttons, eine weitere für DataSets usw. Bitte bedenken Sie, dass es tausende von verschiedenen Objekt-Typen im .NET-Framework gibt.

Aus diesem Grund wurde in .NET 2.0 das „Generics“-Feature eingeführt. Es ermöglicht Ihnen die generische Definition von Klassen (wie eine Klasse, die ähnlich der ArrayList-Klasse ist), aber wenn sie verwendet wird, kann man ihr einen spezifischen Zweck zuweisen. Im folgenden Beispiel sehen Sie die neue List Class, die wie eine generische ArrayList arbeitet:

List<Form> myForms = new List<Form>();
myForms.Add(new Form());
myForms.Add(new Form());
myForms.Add(new Button()); // Compiler Error!!!

In diesem Fall wird ein neues List-Objekt instanziiert, aber mit der Einschränkung, dass ausschließlich Forms in die Auflistung aufgenommen werden können. Der Objekt-Typ wird hierbei in Größer-Kleiner-Zeichen festgehalten. Anstatt zu sagen: „Wir instanziieren eine ArrayList“ würden wir jetzt „Wir instanziieren eine Liste mit Forms“ sagen.

Das ist ein hervorragendes Feature, denn es verbessert einerseits die Qualität des Codes und andererseits auch die Produktivität.

Ein weiteres Beispiel, wie man Generics außerhalb von Collections nutzen kann: Vor kurzer Zeit habe ich einem Kunden geholfen, seine Business Rules zu erstellen. Der Kunde verwendet unsere Milos Solution Platform (Framework) für die Erstellung seiner Applikationen, und Milos ermöglicht die Definition von Business Rules, als wären sie Klassen (wie die meisten Frameworks). Der Kunde wollte eine allgemeine Regel einrichten, die es ihm ermöglicht, jedes Datenfeld mit einem Wert zu vergleichen. Kein Wert sollte hierbei größer sein, als ein bestimmter Wert „X“.

In .NET 1.1 ist das durch sogenannte “IComparable”-Objekte möglich. Viele Objekte, wie auch Integers, Decimals, Strings usw., führen IComparable aus. Damit ist es möglich, „if (x > 0)" abzufragen, womit X mit 0 verglichen wird und true zurückgib, wenn X größer als 0 ist. Es ist auch möglich, ‚if ("B" > "A")' abzufragen, was true zurückgib, weil A vor dem B im Alphabet vorkommt. Dies funktioniert mit jedem Objekt, das IComparable benützt. Daher kann die folgende Methode verwendet werden (C#):

public class MyRule
    public bool
IsGreater(IComparable val1, IComparable val2)
    {
        if (val1.CompareTo(val2) > 0)
        {
            return true;
        }
        else
        {
            return false;
        }
    }
}

Diese Methode kann nun mit 2 Parametern (Integers / Numbers) aufgerufen warden, da Integers IComporable unterstützen. Der folgende Syntax ist also gültig:

MyRule x = new MyRule();
x.IsGreater(10,5);

Der folgende Syntax ist ebenso gültig, da Strings auch IComparable unterstützen:

MyRule x = new MyRule();
x.IsGreater("Athens","Rome");

So weit so gut. Der Knackpunkt ist jedoch, dass beide Parameter nicht nur IComparable unterstützen müssen, sondern vor allem auch vom selben Typ sein müssen. In anderen Worten: Auch, wenn beide Parameter IComparable unterstützen, würde der folgende Syntax nicht funktionieren:

MyRule x = new MyRule();
x.IsGreater(10,"Rome");

Und genau das kann sehr verwirrend sein. Ein typisches Fehlerszenario tritt auf, wenn zwei verschiedene numerische Parameter übergeben werden (beispielsweise decimal und integer). Wir brauchen also eine Möglichkeit, diese zwei Parameter generisch zu übergeben, aber wenn die Methode verwendet wird, müssen beide Parameter zu einem bestimmten Typ „konvertiert“ werden. Und dies ist der Fall, wenn die selbe Methode mit Hilfe der Generics erstellt wirdAnd this can be a bummer, because sometimes this gets confusing. A typical failure scenario would be one where two different numeric types (decimal and integer for instance) are passed. What we need is a way to implement this as generically as demonstrated here, but when the method is used, it needs to be restricted to a specific type. And once again, this can be done when the same method is implemented through generics:

MyRule<int> x = new MyRule<int>();
x.IsGreater(10,20);
x.IsGreater(10,"Rome"); // Compiler Error!!!

Aus meiner Sicht ist das ein sehr brauchbares Anwendungsgebiet von Generics. Es schützt uns vor hunderten von Fehlern, weil wir Strong-Type-Regeln umgehen wollen oder müssen, und unser Code wird beim Kompilieren bereits auf mögliche Fehler geprüft.

Zwischendurch: vor einiger Zeit hat Markus Egger über die Erstellung eines Length-Datentypen (Englisch) gebloggt. Damals haben eine Leser Diskussionen angefangen, ob es wirklich Vorteile bringt, einen neuen Datentyp zu entwickeln, oder ob bestehende Methoden und Objekte aus VFP nicht für denselben Zweck ausreichend sind. Das folgende Business Roule-Beispiel zeigt die Vorteile von eigenen Datentypen auf. Der Length-Datentyp, den er in diesem Beispiel verwendet, kann in der Business Rule-Klasse wie folgt verwendet werden:

MyRule<Length> x = new MyRule<Length>();
x.IsGreater(new Length("5 foot 6 inch"),new Length("1m 25cm"));

Es gibt somit keinen Unterschied zwischen der Verwendung eines eigenen Datentyps und den wesentlichen, bestehenden Datentypen, solange beide Datentypen IComporable unterstützen.

Wenn Sie an weiteren Informationen über Generics interessiert sind, folgen Sie diesem Link aus dem Code:

http://www.code-magazine.com/SearchResults.aspx?search=Generics 



Posted @ 9:26 AM by Jaros, Gerhard (gerhard@eps-software.com) -
Comments (6)


Wednesday, April 12, 2006
LINQ

LINQ stehr fuer "Language Integrated Query" und ist ein neues Feature dass Entwicklern in .NET 3.0 ("Orcas") zur Verfuegung steht. Als FoxPro Programmierer kann man sich LINQ aehnlich der FoxPro DML (Data Manipulation Language) vorstellen. Also z.B. SELECT Befehle, die direkt in .NET Sprachen wie C# oder VB.NET unterstuetzt werden. Einer der grossen Unterschiede ist dass es in .NET keine Unterscheidung zwischen Daten und Objekten gibt. Das hat den Vorteil dass LINQ nicht nur SELECT Befehle ueber Daten absetzen kann, sondern auch auf beliebige Objekte. Z.B. ist es moeglich alle leeren Textboxen auf einem Formular zu selektieren. Es ist auch moeglich SELECTs direkt auf XML Dokumente anzuwenden, usw.

Ich habe unlaengst einen Artikel zu diesem Thema im CoDe Magazine veroeffentlicht. Der Artikel kann sowohl auf der CoDe Magazine Seite, sowie auch hier auf VFPConversion.de online gelesen werden:

Kuerzere Artikel zum selben Thema finden sich auch auf VFPConversion.de unter folgenden Links:

Ein interessanter Externer Artikel befasst sich mit dem XML Support in LINQ (auch bekannt als "XLINQ"):

LINQ ist eine ueberaus interessante Technologie die vor allem FoxPro Programmierern gefallen duerfte. Es ist relativ offensichtlich das viele der FoxPro Ideen in LINQ eingeflossen sind und es sich praktisch um eine Fortfuehrung einer FoxPro Tradition in .NET handelt...

 



Posted @ 8:52 PM by Egger, Markus (markus@code-magazine.com) -
Comments (7)


Thursday, April 06, 2006
Die ersten Workshops sind vorbei...

Die ersten deutschprachigen VFPConversion.de Workshops sind vorbei, und wir freuen uns mitteilen zu koennen dass sie durchwegs als Erfolg einzustufen sind. Man moege es uns hier nachsehen dass wir hier "ins eigene Horn blasen", aber das Feedback der Teilnehmer war durchwegs sehr positiv. Hier einige Beispiele:

Am ersten Tag sehr viele Infos, insbesondere die in VFP nicht/kaum geläufigen OOP-Konzepte Interfaces, Delegates etc. fanden viele interessant.
Allerdings auch verwirrend, aber alle schienen trotzdem zufrieden, weil klar war, dass man mehr Zeit brauchen würde, um die einzelnen Themen zu vertiefen.
Der mehr Praxis orientierte zweite Tag erfüllte voll die Erwartungen.

Ich hab niemanden getroffen, der gesagt hätte, dass die Teilnahme sich nicht gelohnt hätte.
Viele hatten Lust auf mehr.
Alle waren mit Kompetenz und Unterhaltungswert der Redner sehr zufrieden.

In den Newsgroups wurde folgende Message gepostet:

So, gestern abend bin ich mit rauchendem Kopf wieder nach Hause gefahren.:-) Ich möchte mich an dieser Stelle noch mal bei allen beteiligten Leuten von Prolib und EPS bedanken!!! Das war ein prima organisierter Workshop.
Inhaltlich spitze. Bestimmt aber wären zwei Wochen statt zwei Tage besser gewesen ;-)

Direkt per Email ist folgende Nachricht bei uns eingegangen:

Ich möchte mich für den wirklich gelungenen Workshop in Kassel bedanken! Ich habe jetzt nach dem Workshop noch Kontakt zu ein paar Kollegen. Die Aussagen die ich überall höre reichen von „Das ist ja gar nicht so schlimm!“ bis „Ab 2007 mache ich neue Anwendungen nur noch mit DotNet.“

Auch mir geht es da im Prinzip nicht anders. Ich werde VFP auf jeden Fall weiter machen und auch mit VFX zusammen, welches ja wirklich viel Arbeit abnimmt – und damit meine ich nicht die Builder. Aber für neue Sachen möchte ich, gerade wenn es ein WEB-Interface geben soll und Daten auf Oracel oder SQL-Server gehalten werden sollen, durchaus VS benutzen.

Und mal so nebenbei: Was haben wir „VFPler“ eigentlich mit der Datenanbindung für Probleme? Wenn ich in VFP mit Views und CA’s arbeite und meine Daten auf einem SQL-Server habe, ist es doch das selbe in „grün“.

Auch per Email kam folgendes:

Hiermit möchte ich mich nochmals für die sehr informative und professionelle Veranstaltung in Kassel bedanken.

In DotNet entwickeln? Diese Frage hat sich für mich, als eingefleischter Foxpro Entwickler, eigentlich nicht gestellt, denn es gibt ja nichts besseres als Foxpro ;-). Nach dieser Vorstellung bin ich jedoch überzeugt. Mein Fazit: Um die aktuellen Techniken in Zukunft nutzen zu können, geht kein Weg an .Net vorbei, deshalb müssen wir frühzeitig die Weichen in die richtige Richtung stellen und dazu wird es jetzt schon "höchste Eisenbahn". Deshalb wäre ich auch an einer Vertiefung der .Net Kenntnisse interessiert.

Die Workshops scheinen also recht gut angekommen zu sein. Ueber derartiges Feedback freuen wir uns natuerlich sehr.

Es ist auch des oefteren die Frage nach zusaetzlichen Workshops aufgekommen. Zum einen haben wir hier natuerlich vor weitere aehnliche Workshops anzubieten. Der naechste (in Zuerich) ist ja bereits geplant. (Und nebenbei erwaehnt: auch in Nordamerika geht's weiter mit einem Workshop in Montreal). Des weiteren sind wir gerade dabei uns z beraten ob ein fortgeschrittener Workshop ueber mehrere Tage sinnvoll waere. Zu diesem Thema wuerden wir uns ueber Meinungen freuen.

Zusaetzlich gibt's natuerlich immer die Moeglichkeit eine Individualschulung zu diesem Thema bei uns zu buchen...

Mehr Informationen zu allgemeinen Schulungen, sowie Individualschulungen und andere Konvertierungsfragen und -aufgaben gibt's natuerlich auf www.VFPConversion.de.

 

Posted @ 8:37 PM by Egger, Markus (markus@code-magazine.com) -
Comments (4)


Tuesday, March 07, 2006
Die nächsten VFPConversion Workshops...

Die nächsten VFPConversion Workshops finden schon in 2 Wochen in Deutschland und Österreich statt. Mehr Infos dazu gibt es hier für Kassel (Deutschland), und hier für Leogang (Österreich). Ein weiterer Workshop für Zürich (Juni) ist auch bereits geplant. Details dazu gibt es hier.

Es gibt nach wie vor freie Plätze, aber vor allem für den Event in Kassel werden Plätze langsam aber sicher knapp...

Auch für Nordamerika sind Events geplant. Details dazu gibt es hier.

 



Posted @ 9:10 PM by Egger, Markus (markus@code-magazine.com) -
Comments (6)


Monday, March 06, 2006
Viel Glück Ken!

Ken Levy, das Visual FoxPro Urgestein und langzeit Guru hat unlängst seine Position als Microsoft VFP Product Manger verlassen und ist zum Microsoft Windows Live Team übergewechselt. Seine neue Aufgabe ist es für das Live Team eine "Developer Community" aufzubauen.

Dies wurde erstmals im Februar 2006 VFP Newsletter bekanntgegeben. Seit Anfang März führt Ken seine neue Rolle auch aus. Wir wünschen ihm dabei viel Glueck!

Ken selbst hat über seine neue Position geblogged. Mehr dazu lesen Sie hier. Ken wird in der VFP Community sicherlich vermisst werden, und zwar nicht nur in den USA, sondern auch hierzulande. Schliesslich war Ken ja auch auf etlichen Konferenzen im deutschsprachigen Raum und deshalb hier bestens bekannt. Es würde uns jedoch sehr wundern wenn Ken nicht von Zeit zu Zeit in seiner unoffiziellen Rolle als "FoxPro Embassador" wieder auftauchen würde...



Posted @ 8:25 PM by Egger, Markus (markus@code-magazine.com) -
Comments (10)


Thursday, March 02, 2006
VFP-Entwickler tun sich leichter mit .NET
Vor gut 10 Jahren wurde den FoxPro-Entwicklern die objektorientierte Oberfläche "VFP 3.0" vorgestellt. Entsetzen machte sich breit, denn alle Applikationen waren praktisch neu zu formulieren, und niemand bezahlte diese Arbeit. Nun macht sich genau diese Arbeit aber doch bezahlt, nämlich für alle, die es jetzt seit etlichen Jahren gewöhnt sind, Ihre Applikationen - so gut es geht - objektorientiert zu formulieren. Während ein Basic-Programmierer - und ich meine das jetzt nicht böse - mit Objektorientierung noch nichs zu tun hatte, ist dies für den VFP-Entwickler ein bekanntes Terrain, und in Zeiten des ganzen oder partiellen Umstieges auf .NET kann man von diesem Wissen Gebrauch machen. Ein Fox-Programmierer hat es deifinitiv leichter, auf .NET umzusteigen und die Logik zu verstehen, auch, wenn man dazu sagen muss, dass die Objektorientierung in .NET noch einmal einen Quantensprung gegenüber dem uns bekannten System gemacht hat.

In .NET ist einfach ALLES ein Objekt. Ein Menüpunkt, ein ToolTip, ein Registerblatt, die Datentypen, alles ist ein Objekt. Anfangs ist es ein wenig verwunderlich, doch die Vorteile liegen klar auf der Hand: Ich denke, jeder Fox-Programmierer hegte irgendwann einmal den sehnlichen Wunsch, dass eine Tabellenspalte als Objekt zur Verfügung steht. Diese Dinge sind in .NET eine Selbstverständlichkeit.

Gewöhnungsbedürftig - dann aber immens vorteilhaft - ist das Strong Typing in .NET. Strong Typing bedeutet, dass es unmoeglich ist, beispielsweise eine Methode aufzurufen, die nich existiert. Dadurch koennen Fehler wie "Eigenschaft SAVE nicht gefunden, gleich gar nicht passieren.

Ein weiterer Vorteil ist, dass .NET zahlreiche Fehler bereits beim Kompilieren abfaengt, die uns VFP-Entwickler viele Nerven gekostet haben, wie beispielsweise "Variable XYZ nicht gefunden", ebenso Meldungen wie "Wert, Anzahl oder Typ des Funktionsargumentes ungültig."

In diesem Zusammenhang stellt sich die Frage, ob .NET denn gegenüber VFP nur Vorteile hat. Der Fairness halber ist an dieser Stelle natürlich zu sagen, dass FoxPro nicht nur als ein schlechtes Abfallprodukt von Microsoft anzusehen ist, sondern in einigen Bereichen einfacher zu handhaben war, als .NET. Zu Beginn meiner Arbeiten mit .NET hatte ich nennenswerte Schwierigkeiten, das Datenzugriffs-Modell zu verstehen und anzuwenden. Ich vertrete auch weiterhin die Meinung, dass in diesem Bereich FoxPro sehr stark ist, doch hat sich im Laufe der anfänglichen Entwicklungsarbeiten gezeigt, dass für das Datenhandling in .NET lediglich eine andere Perspektive einzusehen ist - und dann ging alles leichter.

Diese Perspektiven wollen wir Ihnen auch in unseren Workshops mit auf den Weg geben.



Posted @ 2:21 PM by Jaros, Gerhard (gerhard@eps-software.com) -
Comments (14)


More Posts: Older Posts

 

 

 

 

 

 

 

Syndication RSS 2.0 RSS 2.0

All My Blogs:
My personal blogs:
Dev and Publishing Dev and Publishing
Travel and Internat. Living Travel and Internat. Living
Other blogs I contribute to:
Milos Blog (US) Milos Blog (US)
VFPConv. Dev Blog (US) VFPConv. Dev Blog (US)
VFPConv. Dev Blog (DE) VFPConv. Dev Blog (DE)

 

Blog Archives
All Blog Posts

2007
    August (1)
    July (1)
    June (2)
    January (1)
2006
    December (1)
    November (2)
    October (1)
    August (1)
    April (3)
    March (3)

 

 

 

This Blog is powered by MilosTM Collaboration Components.