Winforms vs VCL.NET

Bonjour, petite question pour les habitués de dotNET :

Si je demarre la création d'une application, quel intérêt pour moi d'utiliser les Winforms plutôt que la VCL.NET ?
Je vois bcq d'interêt à la VCL.NET, mais vraiment peu pour Winforms, sachant que je ne suis pas interressé par les deux aspects suivants :

* la taille finale de l'executable de l'application
* pas d'utilisation du CompactFramework

Et une deuxième question pour les pros :

Si j'utilise la VCL.NET, suis-je limité à la plateforme Win32 ou puis-je facilement transiter vers Linux par Mono par exemple, ou par CLX ?

La VCL.NET n'est pas utilisable avec le CompactFrameWork ?

Non, VCL.NET supportera CF dans sa version Highlander, voir la roadmap si dessous.

http://homepages.borland.com/davidi/blogpics/DelphiCBuilderRoadmap_lg.jpg

En tous cas, ECO II et ECO III ne fonctionnent pas sur MONO.

Je me pose un peu les même questions.

As tu des réponses à tes questions ?

As tu des réponses à tes questions ?

Non, pas encore, j'expérimente en ce moment.

Envoyé par trident_job

Et une deuxième question pour les pros :

Si j'utilise la VCL.NET, suis-je limité à la plateforme Win32 ou puis-je facilement transiter vers Linux par Mono par exemple, ou par CLX ?

Y a pas de pro pour y répondre ?

Peut etre que la question pourrait etre posée autrement :
Pourquoi y a t il des warning concernant la spécificité à une platforme lorsqu'on compile avec VCL.Net ?

__________________________________

Extrait de "Borland® Delphi® 2005 Migration to .NET using VCL for .NET - by Bob Swart" ( http://bdn.borland.com/article/0,1410,32983,00.html )

This should give you about 17 warnings and 1 error, which are as follows:

[Warning] mastapp.dpr(23): W1005 Unit 'Borland.Vcl.Forms' is specific to a platform
[Warning] MAIN.PAS(6): W1005 Unit 'Borland.Vcl.Windows' is specific to a platform
[Warning] MAIN.PAS(6): W1005 Unit 'Borland.Vcl.Messages' is specific to a platform
[Warning] MAIN.PAS(6): W1005 Unit 'Borland.Vcl.Graphics' is specific to a platform
[Warning] MAIN.PAS(6): W1005 Unit 'Borland.Vcl.Controls' is specific to a platform
[Warning] MAIN.PAS(7): W1005 Unit 'Borland.Vcl.Forms' is specific to a platform
[Warning] MAIN.PAS(7): W1005 Unit 'Borland.Vcl.Dialogs' is specific to a platform
[Warning] MAIN.PAS(7): W1005 Unit 'Borland.Vcl.Buttons' is specific to a platform
[Warning] MAIN.PAS(7): W1005 Unit 'Borland.Vcl.StdCtrls' is specific to a platform
[Warning] MAIN.PAS(7): W1005 Unit 'Borland.Vcl.Menus' is specific to a platform
[Warning] MAIN.PAS(7): W1005 Unit 'Borland.Vcl.ExtCtrls' is specific to a platform
[Warning] DataMod.pas(8 ): W1005 Unit 'Borland.Vcl.Windows' is specific to a platform
[Warning] DataMod.pas(8 ): W1005 Unit 'Borland.Vcl.Messages' is specific to a platform
[Warning] DataMod.pas(8 ): W1005 Unit 'Borland.Vcl.Graphics' is specific to a platform
[Warning] DataMod.pas(8 ): W1005 Unit 'Borland.Vcl.Controls' is specific to a platform
[Warning] DataMod.pas(8 ): W1005 Unit 'Borland.Vcl.Forms' is specific to a platform
[Warning] DataMod.pas(8 ): W1005 Unit 'Borland.Vcl.Dialogs' is specific to a platform
[Fatal Error] DataMod.pas(9): F1026 File not found: 'VarUtils.dcuil'

The warnings can be ignored [mouai, mais ca nous dit pas pourquoi !!]- especially since they are only warnings to tell us that we are using VCL for .NET units that are specific to a platform. To avoid these platform specific warnings, you can disable them if you wish.[on casse le thermomètre comme ça on ne voit pas que la patient a de la fièvre ??]

Est-ce uniquement le cas avec Delphi 2005 ? (car la version "personnel" de D2006 indique la meme chose, donc je suppose que la réponse à cette dernière question est non)

extait de ms-help://borland.bds3/bds3dnetguide/html/LanguageIssues.htm

Utilisation de l'API Win32 non managée

La plus grande partie de la VCL est conçue pour fonctionner avec l'API Windows. Son traitement est similaire à la manière dont Systems.Windows.Forms fonctionne : La VCL est une API managée qui appelle l'API Windows en effectuant le marshaling entre les structures managées du côté VCL et les types non managés utilisés par l'API Windows. Certaines unités, en particulier dans la RTL, ont été portées pour s'installer au-dessus de CLR plutôt que sur l'API Windows. Ces unités sont plus souples, car elles peuvent fonctionner avec n'importe quel environnement .NET, même ceux ne prenant pas en charge le système d'exploitation Windows (par exemple le Compact Framework, Mono, etc.). Les unités qui ont besoin du système d'exploitation Windows sont repérées par la directive platform. Dans les unités qui ne sont pas repérées par la directive platform, toute méthode ou classe nécessitant Windows est repérée au moyen de la directive platform.

Exemple :

Code :

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

1
2
 
unit Borland.Vcl.DBGrids platform;

et

Code :

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

1
2
3
4
5
 
unit Borland.Vcl.SysUtils;
...
function FindNext(var F: TSearchRec): Integer; platform;
...

Code :

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

1
2
3
4
5
6
7
 
unit Borland.Vcl.Classes;
...
  TStream = class(TObject)
  ...
    function Read(var Buffer: Byte; Count: Longint): Longint; overload; platform;
...

Envoyé par trident_job

Si je demarre la création d'une application, quel intérêt pour moi d'utiliser les Winforms plutôt que la VCL.NET ?

Les avantages et inconvénients sont principalement :

VCL.NET : pas de perte de temps, tu es productif tout de suite
WF : il faut malgré tout se former

VCL.NET : événements simple diffusion
WF : multicast events

VCL.NET : grosse lib de base, facilité de migrer des compos win32
WF : petite lib de base, pas mal de choses qui apparaissent en free ou payant

VCL.NET : techniques d'accès aux données "ancienne façon"
WF : accès aux données ADO.NET

VCL.NET : framework 1.1 jusqu'en fin 2006
WF: .NET 2.0 tout de suite (avec VS.NET)


VCL.NET : la road map borland indique une passerelle avec Xaml (mais l'avenir de Delphi depuis le 8 février dernier est incertain)
WF : Aucune passerelle à attendre pour Xaml et WinFX

VCL.NET : passerelle CF prévue pour Highlander (mais même restrictions quant à l'avenir)
WF : Choix sans intérêt pour la compatibilité CF, les WF pour CF sont assez différentes et de toute façon un écran conçu pour PC devra être totalement refait pour tenir dans le minuscule écran d'un smartphone par ex.


On peut trouver encore plein d'autres choses.
Les différences existent et sont bien réelles.
Vu que WinFX sortira dans l'année avec Vista, le mieux c'est pour l'instant de rester sous VCL.NET et de migrer sous WinFX quand ça sortira..

(mais l'avenir de Delphi depuis le 8 février dernier est incertain)

c'est bien de le reconnaitre ...
mais que nous conseilles-tu pour l'avenir ?

Merlin à écrit

VCL.NET : techniques d'accès aux données "ancienne façon"

Même via les composants BDP ?

Vu que WinFX sortira dans l'année avec Vista, le mieux c'est pour l'instant de rester sous VCL.NET et de migrer sous WinFX quand ça sortira..

peut-on en conclure que ta préférence va à la VCL.NET ?

Pour ma part cela fait plus d'une année que je bosse sur Delphi 2006 (avant D2005). Je m'occupe d'ûn gros projet de migration de VCL win32 à VCL.NET.
Dans cette migration, nous avons réécrit complétement qlq modules en WinForm depuis Delphi.
Et ce que je peux en dire de WinForm avec Delphi. Ne l'utilisez pas pour de gros projet !!!!!! Delphi ne support pas l'héritage de Form. Et il est courant que Delphi boussille complétement le design pour des raisons obscures.

VCL.NET Delphi
WF Visual Studio.

Je viens de justement de tester ce type de désagrément.

Pour palier, j'ai remplacer les Form servant de base à l'héritage pas des frames et là plus de soucis.

Moi j'ai regardé comment fait VisualStudio pour l'héritage et je l'ai reproduit en code. Et vu que de toute façon tout est code en WinForm.

Parcontre le soucis avec m'a petite astuce c'est que le Design WinForm de Delphi est complétement au choux. ET du coup ont ne l'utilise plus. C'est comme en C++ avec la MFC

Envoyé par RamDevTeam

Pour palier, j'ai remplacer les Form servant de base à l'héritage pas des frames et là plus de soucis.

Est ce que tu peux nous monter un exemple ?

Dans mon cas, j'ai zappé les winforms.
J'avais un Tform qui me servait de modèle et je l'utilisé comme base pour de nouveau Tform (qui hérité du TFormModele)

Le pb que j'ai rencontré :
dans le TFormModele : pas de gestion de l'evt OnClose de manière à le gérer dans chaque descendant.

Pour toutes les TformXXX héritant de TformModele, les codes d'évenement était purement ignoré.

=> j'ai refait le TformModele dans une frame. ensuite il me suffit de créé des Tform héritant de ... rien ... et d'y poser la frame FrameModele ajuster au client

Dans ce cas les évenemets du Tfom prennent le pas sur les evenement identiques de la frame (sauf si tu précise inherited dans ton code)

Petit désagrément de Delphi si tu fais une frame qui hérite d'une autre :
Dans l'EDI, si la frame servant à l'héritage n'est pas ouverte, delphi est incapable de montrer le visuel des frames descendantes.

ce qui m'intéresse maintenant, c'est de répartir les frames dans des package et de les charger dynamiquement à l'éxecution.

Envoyé par serge-07

c'est bien de le reconnaitre ...
mais que nous conseilles-tu pour l'avenir ?

Comment te répondre, si ce n'est en disant que mon prochain bouquin qui sort fin mars porte au départ le titre "De Delphi à C#" ....
Quans je l'ai écrit les IDE n'était pas en vente mais déjà à cette époque je pensais que la "double compétence" était indispensable.
Aujourd'hui, en raison des interrogations sur l'avenir des IDE borland et le fait que Delphi est en framework 1.1 pour encore un certain temps, il me semble que tout me donne raison...
Abandonner Delphi certainement pas, tant qu'il existe, mais il est temps pour les utilisateurs Delphi de se former à C# pour être professionnellement polyvalents et surtout près à toute éventualité.

Envoyé par RamDevTeam

Merlin à écrit

VCL.NET : techniques d'accès aux données "ancienne façon"

Même via les composants BDP ?

Oui, car le BDP n'existe qu'en mode Windows Forms avec Delphi... Donc pas de VCL.NET avec BDP.
BDP est un fournisseur d'accès qui s'insère dans la logique ADO.NET, et pas du tout dans la logique VCL.
Il y a eu des essais de classes permettant d'utiliser par programmation BDP depuis VCL et de transférer les données dans un TDataset VCL. Je le fait voir dans mon précédent bouquin sur Delphi 8.
Mais bon c'est un peu du bricolage pas très pratique en plus.

peut-on en conclure que ta préférence va à la VCL.NET ?

Tout dépend de l'angle de vue.
Je parlais dans le cas de gens qui restent sous Delphi.net.
Dans ce cas, puisque le choix de Delphi est fait, autant aller au bout de la démarche pour qu'elle soit rentable, donc VCL.NET.

Maintenant si on parle dans l'absolu, je considère qu'au minimum il faut la double compétence C# et dans ce cas de toute façon pas de VCL, mais obligation des WF.
Ensuite on peut se poser une seconde question : si je fais du C# et du Delphi.net, au lieu d'utiliser deux trucs différents, n'aurais je pas intérêt à potentialiser mon savoir, donc à utiliser WF avec les deux puisque c'est le seul choix commun et qu'en plus il sera plus facile de marier les dlls et composants faites avec les deux langages ?
Il est vrai que quitte à faire un composant visuel, autant le faire pour WF ou Webforms... C'est utilisable facilement en Delphi aussi. La VCL elle n'est pas utilisable sous C# ou VB.NET. Dommage de faire le même bouot pour qu'il soit "fermé" alors qu'on peut faire la même chose en restant ouvert.

Beaucoup se posent ensuite une troisième question : maintenant que je sais utiliser C#, maintenant que les WF sont mes amies, au fait, pourquoi je ne fais pas tout en C# ?

... c'est le terrible engrenage qui peut nuire à Delphi, surtout dans la situation actuelle.

Salut,
une petite question en passant,

Envoyé par Merlin

qu'en plus il sera plus facile de marier les dlls et composants faites avec les deux langages ?

abordes-tu cette problématique dans ton prochain livre ?

Envoyé par Laurent Dardenne

abordes-tu cette problématique dans ton prochain livre ?

J'en parle oui, même si c'est pas le sujet principal. Mais des exemples démontrent, notammant dans les parties création de composants web forms et windows forms, que le mixage entre les deux langages est possible. Et on s'aperçoit facilement que dans ce cas le code c# est préférable pour assurer la portabilité entre les deux langages. Mais je laisse le soin au lecteur de conclure, le but du livre c'est de présenter, pas de privilégier un langage sur l'autre.

sur mon site il y a aussi un article "DOTNET Remoting.pdf" où je présente des clients et des serveurs de remoting en c# et Delphi et des exemples où toutes les combinaisons sont possibles. C'est aussi une autre façon de mixer les deux langages.