ATOUTFOX
COMMUNAUTÉ FRANCOPHONE DES PROFESSIONNELS FOXPRO
Visual FoxPro : le développement durable

VFP Compiler Ere post Microsoft   



L'auteur

DLUGEOL
France France
Membre Simple
# 0000000172
enregistré le 26/12/2004

http://www.aloha-intbiz.eu
57 ans
LUGEOL Dominique
Fiche personnelle


Note des membres
pas de note

Contributions > 22 - VFP et .NET

VFP Compiler Ere post Microsoft
# 0000000467
ajouté le 22/08/2007 19:17:52 et modifié le 23/08/2007
consulté 11272 fois
Niveau expert

Version(s) Foxpro :
VFP 9.0

Description

Pour ceux qui ne connaissent pas cette solution, voici quelques infos que je ne manquerai pas de mettre à jour, traduit de l'anglais, extrait de leur site internet www.etechnologia.net :

eTecnologia.net est une société qui développe des solutions basées sur VFP, .NET et C++. Nous sommes des utilisateurs expérimentés sur VFP et connaissons sa puissance.

Nous avons développé plusieures solutions ciblées pour accroitre la puissance de VFP et son intégration dans le framework .NET.

Les deux solutions les plus puissances sont :

  • .NET Extender for VFP. Simplement, cettte solution ouvre VFP à l'ensemble du framework .NET. De nombreux exemples sont inclus, vous permettant de voir comment vous pouvez acceder à toute la puissance du framework .NET dans un langage de développement puissant : Visual FoxPro.
  • VFPCompiler for .NET. La nouvelle génération de compilateur actuellement en version alpha, vous permettant de programmer le framework .NET dans un code VFP et de créer un pure code IL, des appels .NET, qui s'executent nativement par le framework .NET.

Compiler status - Mise à jour du 15 Mai 2007

CategoriesNotre implementation VFP9% complet
Fonctions21344548%
Commandes7717444%

En plus : "Full Independent TableLayer" 64 bits compatible, qui supporte plus de 1000 champs et de grandes tables (supérieures à 4 Go) à démarré.


 

Cette version de support des fichiers VFP, était en cours de développement en Mai 2007, ne supportant à ce moment là que les tables 'FREE', mais la finalisation du développement permettra la gestion complètes des base de données DBC, et le support des fonctions rattachées.

Autres infos extraites ( non traduites ) :

Q. What program is faster, one compiled with VFP or one compiled with the .NET Compiler.

Answer. While the compiler is currently in alpha status it already show big improvements when you use the optional Strong Typing. It could run between 500% to 1000% faster than the VFP version.
Some things to keep in mind if you try the Alpha Version. Use memory variables instead of just the variable name. ? nData could be a field or a memory variable and the runtime tries to look up first like a field and then like a memory variable. So if you know it is a memory variable write ? m.nData.
Even VFP Code compiled as is runs faster as long you keep in mind to reference memory variables with the prefix m. (i.e. m.Variable instead of just Variable).


Q . You mention that you are using VFP language to write the VFP.Runtime. What does it mean? Is VFP runtime module needed to run the thing, or are you just creating a VFP-like language using C# or VB.NET or some such thing?

Answer. The VFP module is not needed at all. I mean our language of choice is VFP because it is the one most programmers know. You can use C#, VB or other .NET languages. We want to ship the source code of the runtime and what better sign of capability / extensibility that to have it implemented in VFP.We hope their language of choice to be VFP.

En clair, cela veux dire que la solution finale ne sera pas dépendante de VFP, ni de son runtime.
A suivre dans les mois à venir...

Info mise à jour du 23/08/2007 :


Good things are happening. We have worked a lot in the GUI classes, so now your VFP controls are .NET Controls! This means you can embed your good old VFP Container / Control into Winforms and by extension Windows Presentation Foundation Apps. So your apps are now .NET apps.
And of course your VFP Forms now can be run in .NET apps and mixed with Winforms. So you keep all the powerful OOP model of VFP Forms and yet you can enable other .NET programmers to use your code.
In the Data front we have implemented APPEND FROM, INSERT INTO, CREATE TABLE (field definitions), also more functions and commands like READ EVENTS, CLEAR EVENTS. Now DateTime types are implemented and the memo functionality is working better.
We have speed up the Data access layer so now it is closer to VFP, and now it looks pretty possible to outperform VFP speed. We will publish a Sample based in the DotNet contest showing our performance very close to the one of VFP, and we are just starting the optimizations game!.
The compiler now supports #DEFINE, #IF and more, so more VFP code is compilable.
Finally with the new GUI functionality in place we are enabling the compiler to be called inside VFP to compile your old PJX project files to .NET (exes or dlls). So in the next revision of the compiler you should not have any need to use the ugly command line to compile your code instead your good VFP will be .NET enabled to produce pure .NET assemblies. This is just the beginning of VFP / .NET Integration.

Deux liens vers des fonctionnalités plus avancées :
http://etecnologia.net/Products/VFPCompiler/CompilingProjectToNet.htm
http://etecnologia.net/Products/VFPCompiler/VFP-GUI01.htm

 

Commentaires
le 22/08/2007, Francis Faure a écrit :
Solution déjà inventoriée, mais qu'en alpha version pour l'instant.
http://www.atoutfox.org/articles.asp?ACTION=FCONSULTER&ID=0000000437
A suivre bien sûr!
Cordialement

le 23/08/2007, FredA a écrit :
De plus, cette solution implique malgrès tout une adaptation du code VFP.
le 23/08/2007, DLUGEOL a écrit :
En réponse à Frédéric : tu dois avoir des infos plus précises, car les miennes ne le mentionnait pas. Peut-être cela sera t il corrigé dans les évolutions à venir...
le 23/08/2007, DLUGEOL a écrit :
Reçu ce jour, par mail : une état d'avancement un peu plus à jour, en suivant dans l'article.

le 23/08/2007, FredA a écrit :
de ce que j'en ai compris, il s'agit d'un compilateur qui générera du .net d'une manière ou d'une autre. (a priori directement du IL)
Pour commencer, Il faudra donc bien indiquer à un moment les fameux using machin
using System.Window.Forms.Form ....
ou alors utiliser les références aux classes parentes du type :
LOCAL oControl AS System::Windows::Forms::Form TLOCAL oControl2 oControl = System::Windows::Forms::Form()

où en VFP on met simplement
LOCAL oControl, oControl2
oControl = CreateObject("Form")
...



Publicité

Les pubs en cours :


www.atoutfox.org - Site de la Communauté Francophone des Professionnels FoxPro - v3.4.0 - © 2004-2024.
Cette page est générée par un composant COM+ développé en Visual FoxPro 9.0-SP2-HF3