en effet... J'avais pas pensé à appliquer la syntaxe de Delphi.net à C# avec add/remove ... :-)
c'est quoi Delphi.net ? est-ce un compilo pour pascal qui target MSIL et avec l'environment de developement et les librairies legacy Delpi? (un peu comme managed C++, version borland)?
ou.. autre chose?....
> Lloyd Dupont a écrit :
c'est assez facile ;-)
en effet...
J'avais pas pensé à appliquer la syntaxe de Delphi.net à C# avec
add/remove ... :-)
c'est quoi Delphi.net ?
est-ce un compilo pour pascal qui target MSIL et avec l'environment de
developement et les librairies legacy Delpi?
(un peu comme managed C++, version borland)?
en effet... J'avais pas pensé à appliquer la syntaxe de Delphi.net à C# avec add/remove ... :-)
c'est quoi Delphi.net ? est-ce un compilo pour pascal qui target MSIL et avec l'environment de developement et les librairies legacy Delpi? (un peu comme managed C++, version borland)?
ou.. autre chose?....
Merlin
Lloyd Dupont a écrit :
c'est quoi Delphi.net ? est-ce un compilo pour pascal qui target MSIL et avec l'environment de developement et les librairies legacy Delpi? (un peu comme managed C++, version borland)? ou.. autre chose?....
Delphi.NET c'est la version .NET de Delphi. Tout simplement. ça existe depuis la version Delphi 8, il y a plus de 2 ans, et Delphi 2005 (qui contient aussi C#) depuis 1 an.
Avantage : sous Windows tu travailles soit en Windows Forms soit avec la VCL.NET, portage .NET de la VCL de Delphi 7. C'est ni plus ni moins natif et ça évite de se prendre la tête ou de tout simplement récupérer facilement des applis Win32 sous .NET, tout en restant natif.
c'est quoi Delphi.net ?
est-ce un compilo pour pascal qui target MSIL et avec l'environment de
developement et les librairies legacy Delpi?
(un peu comme managed C++, version borland)?
ou.. autre chose?....
Delphi.NET c'est la version .NET de Delphi. Tout simplement.
ça existe depuis la version Delphi 8, il y a plus de 2 ans, et Delphi
2005 (qui contient aussi C#) depuis 1 an.
Avantage : sous Windows tu travailles soit en Windows Forms soit avec
la VCL.NET, portage .NET de la VCL de Delphi 7. C'est ni plus ni moins
natif et ça évite de se prendre la tête ou de tout simplement récupérer
facilement des applis Win32 sous .NET, tout en restant natif.
c'est quoi Delphi.net ? est-ce un compilo pour pascal qui target MSIL et avec l'environment de developement et les librairies legacy Delpi? (un peu comme managed C++, version borland)? ou.. autre chose?....
Delphi.NET c'est la version .NET de Delphi. Tout simplement. ça existe depuis la version Delphi 8, il y a plus de 2 ans, et Delphi 2005 (qui contient aussi C#) depuis 1 an.
Avantage : sous Windows tu travailles soit en Windows Forms soit avec la VCL.NET, portage .NET de la VCL de Delphi 7. C'est ni plus ni moins natif et ça évite de se prendre la tête ou de tout simplement récupérer facilement des applis Win32 sous .NET, tout en restant natif.
> Avantage : sous Windows tu travailles soit en Windows Forms soit avec la VCL.NET, portage .NET de la VCL de Delphi 7. C'est ni plus ni moins natif et ça évite de se prendre la tête ou de tout simplement récupérer facilement des applis Win32 sous .NET, tout en restant natif.
mmh... souvent j;entends les utilisateurs de Delphi qui sont tres enthousiaste. comment tu comparerais - VCL par rapport a Winform? - VCL par rapport (Java) Swing?
dans la comparaison VCL <=> Java je suis surtout interesser par les composant complex, c.a.d. JTable, JText, JScrollPane, JTree
ceux la n'on aucun equivalent en C#/Winform. d'aucun diront que si mais les apparence sont trompeuse, par exemple: - JText: composant surpuissant pour adresser tres simplement un problem tres complex - RichTextBox composant merdique qui n'a aucune programabilite (ou presque), n'est pas MVC, ne comprend que le RTF mais pas le C#.....
quoique en Java on peut affecter un texte HTML a tous les control ce qui est la classe comparer a Winform.
> Avantage : sous Windows tu travailles soit en Windows Forms soit avec la
VCL.NET, portage .NET de la VCL de Delphi 7. C'est ni plus ni moins natif
et ça évite de se prendre la tête ou de tout simplement récupérer
facilement des applis Win32 sous .NET, tout en restant natif.
mmh...
souvent j;entends les utilisateurs de Delphi qui sont tres enthousiaste.
comment tu comparerais
- VCL par rapport a Winform?
- VCL par rapport (Java) Swing?
dans la comparaison VCL <=> Java je suis surtout interesser par les
composant complex, c.a.d.
JTable, JText, JScrollPane, JTree
ceux la n'on aucun equivalent en C#/Winform. d'aucun diront que si mais les
apparence sont trompeuse, par exemple:
- JText: composant surpuissant pour adresser tres simplement un problem tres
complex
- RichTextBox composant merdique qui n'a aucune programabilite (ou presque),
n'est pas MVC, ne comprend que le RTF mais pas le C#.....
quoique en Java on peut affecter un texte HTML a tous les control ce qui est
la classe comparer a Winform.
> Avantage : sous Windows tu travailles soit en Windows Forms soit avec la VCL.NET, portage .NET de la VCL de Delphi 7. C'est ni plus ni moins natif et ça évite de se prendre la tête ou de tout simplement récupérer facilement des applis Win32 sous .NET, tout en restant natif.
mmh... souvent j;entends les utilisateurs de Delphi qui sont tres enthousiaste. comment tu comparerais - VCL par rapport a Winform? - VCL par rapport (Java) Swing?
dans la comparaison VCL <=> Java je suis surtout interesser par les composant complex, c.a.d. JTable, JText, JScrollPane, JTree
ceux la n'on aucun equivalent en C#/Winform. d'aucun diront que si mais les apparence sont trompeuse, par exemple: - JText: composant surpuissant pour adresser tres simplement un problem tres complex - RichTextBox composant merdique qui n'a aucune programabilite (ou presque), n'est pas MVC, ne comprend que le RTF mais pas le C#.....
quoique en Java on peut affecter un texte HTML a tous les control ce qui est la classe comparer a Winform.
Merlin
Lloyd Dupont a écrit :
mmh... souvent j;entends les utilisateurs de Delphi qui sont tres enthousiaste.
Il y a certainement de bonnes raisons à cela :-) Je connais même des développeurs qui détestent le langage Delphi, qui s'agenouillent en priant devant le C++ ... mais qui utilisent Delphi pour leur développement car c'est mille fois plus pratique que VC++ tout en étant tout aussi natif. Sous .NET la logique reste la même, le langage a été largement étendu, ce qui lui redonne beaucoup d'intérêt et comparativement à C# il n'y a rien qui soit faisable sous l'un et pas sous l'autre (en dehors des différences syntaxiques propres à chaque langage, sinon ça serait le même). J'aime beaucoup C# cela dit, je l'utilise très souvent, notamment pour tout ce qui est librairie d'objets qui doivent être partagées entre plusieurs langages. Delphi.NET, par sa compatibilité ascendante très appréciable impose aussi quelques petites choses comme la présence d'une petite DLL à déployer ou une gestion des namespaces pas aussi pratique qu'en C#. C'est pas grand chose mais en prenant C# on évite les questions...
comment tu comparerais - VCL par rapport a Winform? - VCL par rapport (Java) Swing?
WinForms, en dehors de la datagrid, c'est un portage rapide des objets win32. L'approche est intéressante (bien supérieur à MFC par exemple) mais on sent, et on sait, que c'est une techno transitoire, pour .NET MS vise XAML. De fait WinForms est la partie que je trouve la moins réussie de .NET, mais cela s'explique donc. L'avantage de Delphi.NET c'est qu'on peut choisir. VCL ou WinForms (ou WebForms). La VCL de son côté existe depuis Delphi 1 sous Win16, elle a évolué, comprend des tonnes de composants et on en trouve des milliers gratuits ou payants sur le web. La VCL est un socle qui permet d'éviter de réinventer la roue à chaque changement de techno. En passant de Win16 à Win32, les applis étaient totalement portables. Il existe une VCL spéciale (VisualCLX) qui permet le passage sous Linux, aujourd'hui la VCL.NET permet le portage du code Win32, et une version spéciale Compact Framework sera intégrée prochainement. Techniquement la VCL.NET fait du P/Invoke sous Windows, comme WinForms. Donc ni plus ni moins natif. Il y a donc une continuité avec VCL à travers les OS et les plateformes. Et c'est très appréciable. Ce n'est pas le cas de WinForms par exemple qui n'a pas de passé, et certainement pas un grand avenir quand XAML se généralisera. Pour Java et swing, le problème c'est java. :-) Je le considère comme le brouillon de C#. Autant ce dernier est clair, logique, élégant, autant je ne sais pas pourquoi j'ai jamais réussi à accroché avec java. Et question portabilité... après avoir fait quelques gros projets et m'être enquiquiné avec les versions différentes de tout un tas de trucs, j'ai abandonné. La VCL est portable sans se prend la tête en comparaison.
dans la comparaison VCL <=> Java je suis surtout interesser par les composant complex, c.a.d. JTable, JText, JScrollPane, JTree
De ce côté là les composants VCL équivalents sont largement plus pratiques (TdbGrid pour les données, TStringGrid pour plus de liberté et afficher ce qu'on veut, TTreeView, etc). En plus la VCL existe depuis longtemps et on trouve des compos tiers sur le web d'excellentes factures qui complètent ou remplacent ceux de base. Certains, notamment pour les grilles, sont étonnants de puissance. VirtualTreeView pour les arbres est un gros projet freeware d'une très grande souplesse. Il y a des centaines d'autres exemples comme cela. C'est ce qui fait l'intérêt de la VCL d'ailleurs. De toute façon en terme d'interface utilisateur swing a longtemps été bien plus lent que l'équivalent natif avec la VCL et Delphi ou les MFC et VC++, ce qui a été rebutant pour plus d'un client. Je n'ai donc pas insisté dans cette voie.
ceux la n'on aucun equivalent en C#/Winform. d'aucun diront que si mais les apparence sont trompeuse, par exemple: - JText: composant surpuissant pour adresser tres simplement un problem tres complex - RichTextBox composant merdique qui n'a aucune programabilite (ou presque), n'est pas MVC, ne comprend que le RTF mais pas le C#.....
Le problème de WinForms c'est sa jeunesse.. et son manque d'avenir. On trouve pas mal de composants sur le web maintenant, mais investir dans une techno transitoire n'est pas un bon choix à mon sens. Je fais du WinForms quand les clients le veulent, mais si je peux j'utilise la VCL.NET, bien plus complète. Je peux aussi reprendre mon investissement Win32 car la portabilité est excellente. Et la base de la POO c'est malgré la ... réutilisation du code, alors si une techno permet de faire de ce voeu une réalité pourquoi s'en priver...
quoique en Java on peut affecter un texte HTML a tous les control ce qui est la classe comparer a Winform.
Oui et c'est normal, Java est plus ancien, et par force c'est un peu comme pour la VCL, on trouve des composants aujourd'hui matures sous Java là ou Winforms est bien pus jeune.
personnellement j'ai pas accroché à java. Je l'ai testé dans de gros projets (je dis bien "gros", à l'époque des projets de plusieurs millions de francs) et ça m'a beaucoup déçu notamment niveau de la portabilité où y'avait pas deux libs qui fonctionnaient correctement selon les versions ou si c'était de chez IBM ou SUN. ça m'a franchement pris la tête. La lenteur et la laideur des affichages par rapport à ce qu'on faisait en Win32 à l'époque m'a pas mal rebuté aussi (et les clients faisaient la gueule...). Depuis ça a évolué, les libs sont mieux, mais bon... les langages c'est comme les gens, on accroche ou pas. Et même en se forçant des fois ça passe pas. Mais y'a des développeurs Java heureux, comme quoi tous les gouts sont dans la nature :-)
mmh...
souvent j;entends les utilisateurs de Delphi qui sont tres enthousiaste.
Il y a certainement de bonnes raisons à cela :-)
Je connais même des développeurs qui détestent le langage Delphi, qui
s'agenouillent en priant devant le C++ ... mais qui utilisent Delphi
pour leur développement car c'est mille fois plus pratique que VC++
tout en étant tout aussi natif.
Sous .NET la logique reste la même, le langage a été largement étendu,
ce qui lui redonne beaucoup d'intérêt et comparativement à C# il n'y a
rien qui soit faisable sous l'un et pas sous l'autre (en dehors des
différences syntaxiques propres à chaque langage, sinon ça serait le
même).
J'aime beaucoup C# cela dit, je l'utilise très souvent, notamment pour
tout ce qui est librairie d'objets qui doivent être partagées entre
plusieurs langages. Delphi.NET, par sa compatibilité ascendante très
appréciable impose aussi quelques petites choses comme la présence
d'une petite DLL à déployer ou une gestion des namespaces pas aussi
pratique qu'en C#. C'est pas grand chose mais en prenant C# on évite
les questions...
comment tu comparerais
- VCL par rapport a Winform?
- VCL par rapport (Java) Swing?
WinForms, en dehors de la datagrid, c'est un portage rapide des objets
win32. L'approche est intéressante (bien supérieur à MFC par exemple)
mais on sent, et on sait, que c'est une techno transitoire, pour .NET
MS vise XAML. De fait WinForms est la partie que je trouve la moins
réussie de .NET, mais cela s'explique donc. L'avantage de Delphi.NET
c'est qu'on peut choisir. VCL ou WinForms (ou WebForms).
La VCL de son côté existe depuis Delphi 1 sous Win16, elle a évolué,
comprend des tonnes de composants et on en trouve des milliers gratuits
ou payants sur le web. La VCL est un socle qui permet d'éviter de
réinventer la roue à chaque changement de techno. En passant de Win16 à
Win32, les applis étaient totalement portables. Il existe une VCL
spéciale (VisualCLX) qui permet le passage sous Linux, aujourd'hui la
VCL.NET permet le portage du code Win32, et une version spéciale
Compact Framework sera intégrée prochainement. Techniquement la VCL.NET
fait du P/Invoke sous Windows, comme WinForms. Donc ni plus ni moins
natif.
Il y a donc une continuité avec VCL à travers les OS et les
plateformes. Et c'est très appréciable. Ce n'est pas le cas de WinForms
par exemple qui n'a pas de passé, et certainement pas un grand avenir
quand XAML se généralisera.
Pour Java et swing, le problème c'est java. :-) Je le considère comme
le brouillon de C#. Autant ce dernier est clair, logique, élégant,
autant je ne sais pas pourquoi j'ai jamais réussi à accroché avec java.
Et question portabilité... après avoir fait quelques gros projets et
m'être enquiquiné avec les versions différentes de tout un tas de
trucs, j'ai abandonné. La VCL est portable sans se prend la tête en
comparaison.
dans la comparaison VCL <=> Java je suis surtout interesser par les composant
complex, c.a.d.
JTable, JText, JScrollPane, JTree
De ce côté là les composants VCL équivalents sont largement plus
pratiques (TdbGrid pour les données, TStringGrid pour plus de liberté
et afficher ce qu'on veut, TTreeView, etc). En plus la VCL existe
depuis longtemps et on trouve des compos tiers sur le web d'excellentes
factures qui complètent ou remplacent ceux de base. Certains, notamment
pour les grilles, sont étonnants de puissance. VirtualTreeView pour les
arbres est un gros projet freeware d'une très grande souplesse. Il y a
des centaines d'autres exemples comme cela. C'est ce qui fait l'intérêt
de la VCL d'ailleurs.
De toute façon en terme d'interface utilisateur swing a longtemps été
bien plus lent que l'équivalent natif avec la VCL et Delphi ou les MFC
et VC++, ce qui a été rebutant pour plus d'un client. Je n'ai donc pas
insisté dans cette voie.
ceux la n'on aucun equivalent en C#/Winform. d'aucun diront que si mais les
apparence sont trompeuse, par exemple:
- JText: composant surpuissant pour adresser tres simplement un problem tres
complex
- RichTextBox composant merdique qui n'a aucune programabilite (ou presque),
n'est pas MVC, ne comprend que le RTF mais pas le C#.....
Le problème de WinForms c'est sa jeunesse.. et son manque d'avenir. On
trouve pas mal de composants sur le web maintenant, mais investir dans
une techno transitoire n'est pas un bon choix à mon sens.
Je fais du WinForms quand les clients le veulent, mais si je peux
j'utilise la VCL.NET, bien plus complète. Je peux aussi reprendre mon
investissement Win32 car la portabilité est excellente. Et la base de
la POO c'est malgré la ... réutilisation du code, alors si une techno
permet de faire de ce voeu une réalité pourquoi s'en priver...
quoique en Java on peut affecter un texte HTML a tous les control ce qui est
la classe comparer a Winform.
Oui et c'est normal, Java est plus ancien, et par force c'est un peu
comme pour la VCL, on trouve des composants aujourd'hui matures sous
Java là ou Winforms est bien pus jeune.
personnellement j'ai pas accroché à java. Je l'ai testé dans de gros
projets (je dis bien "gros", à l'époque des projets de plusieurs
millions de francs) et ça m'a beaucoup déçu notamment niveau de la
portabilité où y'avait pas deux libs qui fonctionnaient correctement
selon les versions ou si c'était de chez IBM ou SUN. ça m'a franchement
pris la tête. La lenteur et la laideur des affichages par rapport à ce
qu'on faisait en Win32 à l'époque m'a pas mal rebuté aussi (et les
clients faisaient la gueule...).
Depuis ça a évolué, les libs sont mieux, mais bon... les langages c'est
comme les gens, on accroche ou pas. Et même en se forçant des fois ça
passe pas. Mais y'a des développeurs Java heureux, comme quoi tous les
gouts sont dans la nature :-)
mmh... souvent j;entends les utilisateurs de Delphi qui sont tres enthousiaste.
Il y a certainement de bonnes raisons à cela :-) Je connais même des développeurs qui détestent le langage Delphi, qui s'agenouillent en priant devant le C++ ... mais qui utilisent Delphi pour leur développement car c'est mille fois plus pratique que VC++ tout en étant tout aussi natif. Sous .NET la logique reste la même, le langage a été largement étendu, ce qui lui redonne beaucoup d'intérêt et comparativement à C# il n'y a rien qui soit faisable sous l'un et pas sous l'autre (en dehors des différences syntaxiques propres à chaque langage, sinon ça serait le même). J'aime beaucoup C# cela dit, je l'utilise très souvent, notamment pour tout ce qui est librairie d'objets qui doivent être partagées entre plusieurs langages. Delphi.NET, par sa compatibilité ascendante très appréciable impose aussi quelques petites choses comme la présence d'une petite DLL à déployer ou une gestion des namespaces pas aussi pratique qu'en C#. C'est pas grand chose mais en prenant C# on évite les questions...
comment tu comparerais - VCL par rapport a Winform? - VCL par rapport (Java) Swing?
WinForms, en dehors de la datagrid, c'est un portage rapide des objets win32. L'approche est intéressante (bien supérieur à MFC par exemple) mais on sent, et on sait, que c'est une techno transitoire, pour .NET MS vise XAML. De fait WinForms est la partie que je trouve la moins réussie de .NET, mais cela s'explique donc. L'avantage de Delphi.NET c'est qu'on peut choisir. VCL ou WinForms (ou WebForms). La VCL de son côté existe depuis Delphi 1 sous Win16, elle a évolué, comprend des tonnes de composants et on en trouve des milliers gratuits ou payants sur le web. La VCL est un socle qui permet d'éviter de réinventer la roue à chaque changement de techno. En passant de Win16 à Win32, les applis étaient totalement portables. Il existe une VCL spéciale (VisualCLX) qui permet le passage sous Linux, aujourd'hui la VCL.NET permet le portage du code Win32, et une version spéciale Compact Framework sera intégrée prochainement. Techniquement la VCL.NET fait du P/Invoke sous Windows, comme WinForms. Donc ni plus ni moins natif. Il y a donc une continuité avec VCL à travers les OS et les plateformes. Et c'est très appréciable. Ce n'est pas le cas de WinForms par exemple qui n'a pas de passé, et certainement pas un grand avenir quand XAML se généralisera. Pour Java et swing, le problème c'est java. :-) Je le considère comme le brouillon de C#. Autant ce dernier est clair, logique, élégant, autant je ne sais pas pourquoi j'ai jamais réussi à accroché avec java. Et question portabilité... après avoir fait quelques gros projets et m'être enquiquiné avec les versions différentes de tout un tas de trucs, j'ai abandonné. La VCL est portable sans se prend la tête en comparaison.
dans la comparaison VCL <=> Java je suis surtout interesser par les composant complex, c.a.d. JTable, JText, JScrollPane, JTree
De ce côté là les composants VCL équivalents sont largement plus pratiques (TdbGrid pour les données, TStringGrid pour plus de liberté et afficher ce qu'on veut, TTreeView, etc). En plus la VCL existe depuis longtemps et on trouve des compos tiers sur le web d'excellentes factures qui complètent ou remplacent ceux de base. Certains, notamment pour les grilles, sont étonnants de puissance. VirtualTreeView pour les arbres est un gros projet freeware d'une très grande souplesse. Il y a des centaines d'autres exemples comme cela. C'est ce qui fait l'intérêt de la VCL d'ailleurs. De toute façon en terme d'interface utilisateur swing a longtemps été bien plus lent que l'équivalent natif avec la VCL et Delphi ou les MFC et VC++, ce qui a été rebutant pour plus d'un client. Je n'ai donc pas insisté dans cette voie.
ceux la n'on aucun equivalent en C#/Winform. d'aucun diront que si mais les apparence sont trompeuse, par exemple: - JText: composant surpuissant pour adresser tres simplement un problem tres complex - RichTextBox composant merdique qui n'a aucune programabilite (ou presque), n'est pas MVC, ne comprend que le RTF mais pas le C#.....
Le problème de WinForms c'est sa jeunesse.. et son manque d'avenir. On trouve pas mal de composants sur le web maintenant, mais investir dans une techno transitoire n'est pas un bon choix à mon sens. Je fais du WinForms quand les clients le veulent, mais si je peux j'utilise la VCL.NET, bien plus complète. Je peux aussi reprendre mon investissement Win32 car la portabilité est excellente. Et la base de la POO c'est malgré la ... réutilisation du code, alors si une techno permet de faire de ce voeu une réalité pourquoi s'en priver...
quoique en Java on peut affecter un texte HTML a tous les control ce qui est la classe comparer a Winform.
Oui et c'est normal, Java est plus ancien, et par force c'est un peu comme pour la VCL, on trouve des composants aujourd'hui matures sous Java là ou Winforms est bien pus jeune.
personnellement j'ai pas accroché à java. Je l'ai testé dans de gros projets (je dis bien "gros", à l'époque des projets de plusieurs millions de francs) et ça m'a beaucoup déçu notamment niveau de la portabilité où y'avait pas deux libs qui fonctionnaient correctement selon les versions ou si c'était de chez IBM ou SUN. ça m'a franchement pris la tête. La lenteur et la laideur des affichages par rapport à ce qu'on faisait en Win32 à l'époque m'a pas mal rebuté aussi (et les clients faisaient la gueule...). Depuis ça a évolué, les libs sont mieux, mais bon... les langages c'est comme les gens, on accroche ou pas. Et même en se forçant des fois ça passe pas. Mais y'a des développeurs Java heureux, comme quoi tous les gouts sont dans la nature :-)
