Discussion :

[RamDevTeam]

Qui utilise ce type d'appli ?
Est-ce toujours disponible dans les dernières versions de delphi ?

[ShaiLeTroll]

Tu as l'équivalent, Delphi Prism qui est vraiement .NET,
Je ne connais pas la VCL.NET mais il me semble que ce n'est plus compatible !

en même temps, confirme !

Does Delphi Prism include support for VCL.NET?
No. Development for VCL.NET has been deprecated and will not be supported in Delphi Prism. Developers using VCL.NET can either use Delphi 2007 to continue those products or can migrate their VCL.NET applications to VCL for Win32.

[RamDevTeam]

C'est malheureusement ce que je viens de voir ...
Comme c'était aussi simple que ca de migrer son code en vcl win32

Entre ca et ECO qui ne suit plus non plus ... que des bonnes nouvelles

[Paul TOTH]

C'est malheureusement ce que je viens de voir ...
Comme c'était aussi simple que ca de migrer son code en vcl win32

Entre ca et ECO qui ne suit plus non plus ... que des bonnes nouvelles

en même temps je ne comprend pas bien l'intérêt de faire du .Net avec Delphi...la VCL n'a pas besoin de .Net et .Net n'a pas besoin de la VCL...enfin c'est mon avis que je partage avec moi même

[RamDevTeam]

VCL.NET permettait de continuer à développer comme en version win32, tout en bénéficiant des fonctionnalités .net
L'idée était prometteuse.

Quand BDS2005 est sortie, une des grandes nouveautés à mon sens étaient la possibilité d'utiliser un framework O/R.
2 possibilités pour cela :
- VCL.NET
- Delphi.Net
Quand on a des composants tiers uniquement dispo pour la VCL on n'a pas tellement le choix. il faut s'orienter vers VCL.NET

Le gros problème =>
ECO II apparaît en D2005, est amélioré avec BDS2006 (ECO III) ,puis est supporté avec RAD Studio 2007( ECO IV) (mais la licence n'est plus incluse à cause de la séparation vers CapableObject) puis tout s'arrête.

C'est la première fois depuis que j'utilise delphi que la migration vers une version plus récente entraine autant de travail de réécriture ...

La seule solution pour actualiser une application VCL.NET + ECO ... c'est refaire TOUT les accès aux données pour repartir vers une gestion type Dbexpress.

un exemple simplifié.
Pour connaitre l'adresse de livraison d'un client pour un commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
procedure DisplayAdresseLivraison( oCommande : CommandeClient);
var 
 oadr : adresse;
[..]
 oadr := maCommande.Client.AdresseLivraison;
 Memo_Adresse.lines.add( oadr.NatureEtVoie);
Memo_Adresse.lines.add( oadr.CodePostal + ' ' + oadr.Ville);
[..]

la même chose sans ECO =>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
procedure DisplayAdresseLivraison( idCommande : integer);
begin
    MyQuery.sql.add('SELECT ADRESSE.* FROM commande inner join client on (client.idclient = commande.idClient)  ');
MyQuery.sql.add('inner join adresse on (client.AdresseLivraison = Adresse.IdAdresse) ');
MyQuery.sql.add('WHERE Commande.idCommande = ' + inttostr(idCommande) ); 
 
  MyQuery.open
 
  if not MyQuery.eof then
  begin
    Memo_Adresse.lines.add( MyQuery.fieldbyname('NatureEtVoie').asstring);
    Memo_Adresse.lines.add(  MyQuery.fieldbyname('CodePostal().asstring + ' ' + MyQuery.fieldbyname('Ville').asstring);
  end;
 
end;

Je ne parle même pas du pilotage office via les assemblys .net qu'il faut également refaire.

[Paul TOTH]

je ne connais pas ECO (uniquement Umberto) mais il est possible de créer les classes nécessaire à la compilation du premier code au lieu de tout réécrire.

alors j'imagine que ECO permet de maintenir ces classes en fonction des modifications de la BDD ...sinon à quoi sert-il ?...mais si tu estimes que cette approche est la meilleur, il est possible de le faire en pur Pascal, ce qui m'a toujours semblé être la meilleur solution. Car du pur Pascal se compile aussi bien sous W32 que sous .Net (et autre avec FreePascal)