Discussion :

[nostroyo]

Je suis bien d'accord comparer delphi et winDev

Je dirais même que ce n'est pas comparable tant les buts de ces deux produits sont différents.

Mais bon là n'est pas la question. En tout cas continuer vos retours d'expérience que je vois si je passe a 2009.

[skywaukers]

Bonjour,

Le ruban, effectivement pas vraiment au point. Flickering très important. C'est pourtant un vieux problème de Delphi.

Oui c'est dommage, mais ce n'est qu'un problème visuel, et nul doute qu'il sera amélioré.

Pas de problème avec Ctrl-C, l'Ide a l'air stable. Seul point positif, la rapidité à l'ouverture.

Ca c'est très positif, surtout la stabilité parce qu'à partir de là le temps de chargement devient moins important.

Question productivité, faudrait peut-être que Codegear s'inspire de Windev, question sens pratique. On dirait que chaque nouvelle version de Delphi se contente de rajouter quelques rustines pour suivre l'évolution technologique, mais sans jamais remettre de l'ordre dans l'existant.

Résultat : l'aide - un fouillis sans fin, l'inspecteur d'objet et la palette de composants - une garantie de perte de temps... du travail à la soviétique. Et le flickering interdit toujours l'utilisation d'images de fond pour améliorer l'interface, sous peine de migraine garantie pour l'utilisateur final.

Alors là je ne suis absolument pas d'accord !! l'IDE de Delphi 2009 est bien plus productif comparé à celui de Delphi 7. Les templates de code par exemple, toute les possibilités de refactoring, l'aide au positionnement sur les forms. Quant à la palette de composant, il y a ce qui manquait énormément dans Delphi 7 justement : une zone de recherche de composant.
Quant à la comparaison avec windev je pense que c'est de la provocation là parce que franchement ce n'est pas vraiment comparable. Certe pour faire une appli type de gestion en utilisant les technos pure windev (langage + bdd) c'est sûr que la productivité est énorme, mais il ne faut pas avoir besoin de s'en écarter sous peine de perdre la productivité, il n'y a pas de miracle.
Quant aux évolutions à la rustine comme tu dis, c'est l'héritage de Borland qui a trop longtemps tergiversé, hésitant entre java et Delphi, puis entre .Net et Delphi, faisant presque de Delphi une passerelle vers VS. Maintenant ce n'est plus Borland et Delphi 2009 est encore une version qui n'est pas 100% Embarcadero.
Je ne travaille pas pour eux et n'ai aucune action chez eux, je suis juste un mordu de Delphi, alors pour moi il faudrait montrer une vrai volonté de laisser notre vieille et très bonne version de Delphi pour évoluer vers la nouvelle version, en donnant le plus de retours possible à Embarcadero. Car si Delphi est vraiment porteur pour eux, nul doute qu'ils investiront à fond dedans et que les évolutions seront au rendez-vous.

@++
Dany

[belgianfool]

Comme je le disais, tout dépend de ce que l'on attend d'un outil de développement. Voir aussi qui achète la licence... un patron ou alors c'est un investissement personnel.

Pour moi D 2009 est encore une version de transition... mais qui coûte comme les autres, même au tarif upgrade.

Concernant Windev, j'ai longtemps été réticent à l'utiliser, mais chaque nouvelle version apporte une quantité importante de nouveautés et lentement, il finit par gérer beaucoup de choses que Delphi ne peut gérer sans recours aux APIs ou alors aux composants payants, je pense aux clés USB, aux fonctions de gravure, à l'intégration avec Office et OpenOffice, à la diversité des affichages graphiques, aux fiches multiniveau... La version 12 est loin, très loin de la 7.5, il en existe une version démo (express) gratuite très instructive.

Le problème de Windev reste sa vitesse d'exécution, comme tout environnement interprété, et même avec le nouveau JIT. (autre problème, la persistance des bugs, mais là, Delphi n'est pas en reste).

Mon propos est de dire que quand on voit ce qu'une petite boîte française peut produire, sans moyens énormes, on se demande pourquoi une boîte avec l'expérience de Borland/Codegear vend encore des outils qui donnent l'impression d'être produits dans l'urgence et juste pour rentrer des finances pour maintenir la boîte à flots.

Bref, mon impression est que quand je suis passé il y a bien longtemps de MFC 4 et VB 4 à Delphi 3, j'ai eu l'impression de faire un bond en avant, maintenant, je trouve que la relation entre Visual Studio et Delphi est exactement inverse. Bien sûr, Visual Studio ne fait plus du Win32 que sous MFC ou les APIs, et VS 2008 n'apporte pas grand chose de plus que VS 2005.

Donc pourquoi pas Windev un de ces jours, ou alors Qt ? L'important pour moi est de savoir comment on peut encore faire une appli sur mesure en moins d'un mois avec impressions, backups et tout (et sans me faire jeter à la première démo parce que mes fenêtres "clignotent" quand on les redimensionne, alors que celles de n'importe quel antivirus, non !).

Sinon, rdv à Delphi 2010... qui sait...

[Reisubar]

Pour moi D 2009 est encore une version de transition... mais qui coûte comme les autres, même au tarif upgrade.

Ce qui est sûr, c'est que les premiers utilisateurs essuieront les plâtres de la toute nouvelle VCL Unicode. Je pense qu'il faudra quelques updates pour avoir un produit totalement fonctionnel sur ce point. Néanmoins, je ne pense pas qu'on puisse parler de "transition" pour un produit qui a subi un nombre incalculable de changements internes pour s'extraire de l'API ANSI datant de Delphi 2. Pour moi, c'est la première version qui introduit un vrai changement majeur depuis D7, et je trouve ca vraiment positif.

[skywaukers]

Comme je le disais, tout dépend de ce que l'on attend d'un outil de développement. Voir aussi qui achète la licence... un patron ou alors c'est un investissement personnel.

Oui c'est sur que pour un investissement personnel windev est moins cher, pour un patron c'est un investissement, alors après il faut voir d'autres critères. Pour une petite structure qui n'a besoin que de petits outils bureautiques ou de gestion sur un petit réseau alors oui windev peut faire l'affaire. Maintenant dans le contexte d'une grosse structure avec des centaines d'utilisateurs répartis dans le monde, un réseau pas toujours au top, des architectures hétérogènes, là windev est hors sujet, Delphi non. Donc oui tu as raison, tout dépend...

Pour moi D 2009 est encore une version de transition... mais qui coûte comme les autres, même au tarif upgrade.

Oui... Et windev 12, ce n'est pas une version de transition entre windev 11 et windev 13 ?

Concernant Windev, j'ai longtemps été réticent à l'utiliser, mais chaque nouvelle version apporte une quantité importante de nouveautés et lentement, il finit par gérer beaucoup de choses que Delphi ne peut gérer sans recours aux APIs ou alors aux composants payants, je pense aux clés USB, aux fonctions de gravure, à l'intégration avec Office et OpenOffice, à la diversité des affichages graphiques, aux fiches multiniveau... La version 12 est loin, très loin de la 7.5, il en existe une version démo (express) gratuite très instructive.

La pluparts des choses que tu cites peuvent se faire avec des composants ou des librairies gratuites (notamment Tout ce qui touche office et même open office (il y a même un tuto sur ce site)). Tu vois là la différence c'est que avec windev tu fais ce que permet de faire windev, sinon tu prie pour que pcsoft pense à l'intégrer dans la prochaine version. Avec Delphi non, tu peux trouver des tas de ressources, voir selon ton niveau et ton temps le faire toi même. Tiens les ribbons barre viennent d'être intégré, mais ça fait longtemps qu'on pouvait faire des applis avec ce look grâce à des ressources externes. Ca se discute tout ça, payer un peu pour avoir tout de suite ou attendre.... on en revient au début ça dépend si s'est pour un dev perso ou pour une boite.

(autre problème, la persistance des bugs, mais là, Delphi n'est pas en reste).

Alors c'est vrai qu'ils ont dû faire beaucoup de progrès car la dernière fois que j'ai testé ct quand même bien plus buggué que Delphi.

Mon propos est de dire que quand on voit ce qu'une petite boîte française peut produire, sans moyens énormes, on se demande pourquoi une boîte avec l'expérience de Borland/Codegear vend encore des outils qui donnent l'impression d'être produits dans l'urgence et juste pour rentrer des finances pour maintenir la boîte à flots.

La dessus je te rejoints oui. Le problème à mon avis est la diversification de Borland. PCSoft n'a que windev à faire évoluer. Borland lui s'est égaré entre java .net, puis la gestion du cycle de vie. Sa position de rival à microsoft lui a valu aussi les foudres de ce dernier qui l'ont affaiblit financièrement à une période, l'obligeant à se séparer de ses meilleurs éléments, et notamment de l'âme de Delphi.
PCSoft lui a évolué doucement, sans déranger. Il reste quand même que c'est un produit franco français qui ne compte pas non plus des millions d'utilisateurs. Et puis il faut reconnaitre qu'ils sont très fort en marketing (il ne faut pas oublier qu'il y a 2-3 ans ils ont annoncés avoir inventés le développement par composants, autant en rire ) ).
Reste que Codegear devrait s'en inspirer un peu je suis bien d'accord. Mais encore une fois les deux produits ne sont pas vraiment comparables, windev étant trop cantonné à l'application de gestion pour petites structures.

Bien sûr, Visual Studio ne fait plus du Win32 que sous MFC ou les APIs, et VS 2008 n'apporte pas grand chose de plus que VS 2005.

Ben voilà, Embarcadero semble l'avoir compris, il y a de la place pour un bon outil Win32. Et il y a la place pour un vrai concurrent sous .NET à condition de ne pas continuer dans la lignée de Borland.

Donc pourquoi pas Windev un de ces jours, ou alors Qt ? L'important pour moi est de savoir comment on peut encore faire une appli sur mesure en moins d'un mois avec impressions, backups et tout (et sans me faire jeter à la première démo parce que mes fenêtres "clignotent" quand on les redimensionne, alors que celles de n'importe quel antivirus, non !).

Il ne faut quand même pas exagérer, c'est pas parce que les ribbons barre ne sont pas fluides qu'il faut généraliser ! Je fais pleins d'applications professionnelles avec Delphi dont les fenêtres sont aussi fluides que celles des anti-virus (d'ailleurs moi j'ai avast, je n'ai pas vu de ribbon barre dedans, que des ihm très simple et efficaces, c'est en fait surtout cela l'important) et je ne me suis jamais fais jeter à cause de ce genre de problème.
Et puis là faut remettre les pieds sur terre, les application sapin de noël c'est joli 5 minutes. C'est vrai que c'est important que ce soit agréable à l'oeil de l'utilisateur, mais une fois qu'il aura bien vu tous les gadgets visuel de l'application il n'y prètera plus d'intérêt et alors là il faudra que l'application soit conviviale (conviviale, ne veut pas dire que beau, non) et fonctionnelle, et là les petits effets graphiques qui vont la ralentir, ceux pour quoi il l'aura peut-être même choisit, et bien ils l'agaceront.
Rien ne vaut une interface bien pensée, intuitive pour l'utilisateur. Et même si il n'y a pas les dernières fioritures à la mode je fais le pari tous les jours que l'utilisateur en sera plus satisfait.

@++
Dany

[Franck SORIANO]

Moi il y a une chose qui m'inquiête beaucoup avec D2009 : Le support unicode va poser de très gros problèmes de compatibilité dans les applis existantes.

Si j'ai bien compris, pour gérer l'unicode, le type string est implicitement devenu une chaîne UTF-16. Le char est devenu un widechar, le PChar est devenu un PWideChar...
Ca veut dire que si on prend une appli existante, et qu'on la recompile avec D2009, on obtient une appli différente de celle qui avait été codée...

Le moindre bout de code qui utilisait les API Win32 va cesser de fonctionner. Les structures ne seront plus alignées correctement, on va passer des caractères unicodes aux versions ANSI des API...
Chaque fois qu'on utilisait un string en guise de buffer, ça ne fonctionnera plus. Il va falloir revoir tous les Move, FillChar...
Si on utilisait des PChar pour bénéficier de l'arithmétique des pointeurs, ben maintenant le code fera n'importe quoi... (heureusement que je cast mes pointeurs en integer).
De plus, la VCL était la première à faire ce genre de chose (les buffers des dataset sont typés en PChar). Donc j'imagine que la VCL elle même a dû être modifiée pour utiliser d'autres types, et mes composants ne vont même plus compiler.

Et le pire dans tous ça, c'est qu'on ne verra pratiquement rien à la compil. Le code va compiler et faire n'importe quoi à l'exécution... c'est pire que lors du passage à D6 avec l'unité Variants.

J'ai une appli qui fait 1 500 000 lignes de code. Initialement écrite pour D6, avec des composants tiers qui ne sont parfois plus supportés.
Il est totalement inenvisageable de repasser sur chaque ligne de code pour la rendre compatible unicode...
Autant dire que je ne pourrais jamais passer à D2009.
C'est vraiment dommage, car depuis que j'ai goûté aux générics avec C#, je ne peux plus m'en passer.

Franchement, avec le support unicode, je n'attendais qu'une seule chose : Que la VCL soit modifiée pour que les propriétés de type string deviennent des WideString et que les composants s'appuient sur la version unicode des fonctions de l'API Win32. Pas un changement aussi drastique que ce qui a été fait.

D'autant plus que honnêtement, on n'a besoin de l'Unicode que pour écrire des appli internationnales qui doivent supporter simultanément plusieurs jeux de caractères. Sinon, on s'en sort très bien avec les codes pages.

Bref l'unicode, j'aurais très bien pu m'en passer. Par contre à cause de lui, je ne pourrais pas passer à D2009, ni aux versions suivantes. Je n'ai plus qu'à convaincre mon employeur de migrer en C#...

[Lung]

Arg. C'est une info qui m'intéresse aussi, çà.
Faut que je fasse des tests.

[skywaukers]

Bonsoir,

as-tu contacter Codegear à ce sujet ? Ce que tu dis se tient complètement, mais ça me parait quand même énorme qu'ils aient fait ça comme ça sans au moins faire une information préalable pour que tout le monde se prépare, un peu comme ça avait été fait lorsqu'ils avaient modifiés l'organisation des composant ou quand ils ont arrêté l'évolution du BDE.

@++
Dany

[DenDemble]

Moi il y a une chose qui m'inquiête beaucoup avec D2009 : Le support unicode va poser de très gros problèmes de compatibilité dans les applis existantes.

bon je m'avance un peu (pas encore testé ce que j'affirme) mais, si on n'a pas besoin d'unicode sous D2009,
ne suffit t il pas de mettre le type ansistring à la place de string pour toutes les variables/propriétés concernées afin que l'application se comporte comme avant ?

[swierzbicki]

J'ai une appli qui fait 1 500 000 lignes de code. Initialement écrite pour D6, avec des composants tiers qui ne sont parfois plus supportés
....
Bref l'unicode, j'aurais très bien pu m'en passer. Par contre à cause de lui, je ne pourrais pas passer à D2009, ni aux versions suivantes. Je n'ai plus qu'à convaincre mon employeur de migrer en C#...

Je comprends vos craintes ! Cependant, i vous avez les sources de vos composants tiers, rien n'est insurmentable.

Je pense sincèrement que vous passerez plus de temps à ré-ecrire votre application de A à Z en C#.Net (pensez aux composants tiers ou fonctions non dispos sous .Net, voir de repenser à la structure de votre programme) que de modifier votre code pour qu'il compile sous D2009.

Pour info, le compileur remonte pas mal d'info quant aux potentiel problèmes de conversions liés à l'unicode... ce qui est fort utile pour migrer votre application.

[Franck SORIANO]

Bonsoir,

as-tu contacter Codegear à ce sujet ? Ce que tu dis se tient complètement, mais ça me parait quand même énorme qu'ils aient fait ça comme ça sans au moins faire une information préalable pour que tout le monde se prépare, un peu comme ça avait été fait lorsqu'ils avaient modifiés l'organisation des composant ou quand ils ont arrêté l'évolution du BDE.

@++
Dany

Non, mais c'est ce que j'ai pu lire à droite à gauche :
http://www.phwinfo.com/forum/nzn-fr-...9-tiburon.html
http://www.jacobthurman.com/?p=27
http://www.jacobthurman.com/?p=28
http://www.jacobthurman.com/?p=29
http://www.jacobthurman.com/?p=31

ne suffit t il pas de mettre le type ansistring à la place de string pour toutes les variables/propriétés concernées afin que l'application se comporte comme avant ?

A priori si, AnsiString à la place de string, AnsiChar à la place de Char, PAnsiChar à la place de PChar...
Mais j'ai qu'en même un doute que ça suffise, il faudrait essayer. Il y a de fortes chances que je me retrouve avec un effet de bord quel que part où il ne faut pas.
Sans compter que je ne peux pas modifier les routines de la VCL pour qu'elles travaillent en Ansi et pas en unicode. Donc il va y avoir des convertions dans tous les sens, et une dégradation des perfs. Ou alors je serais inondé de milliers de warnings (remarque, l'un n'empêche pas l'autre ).

De plus j'ai cru comprendre que maintenant, les applis compilées avec D2009 ne fonctionneront plus avec Win9x car ces OS ne supportent pas l'Unicode. Il y a encore 3 ans, je connaissais de très grosses boîtes (le principal client de mon ancien employeur) qui était toujours sous Win95 et qui ne voulait pas migrer parce qu'ils n'avaient toujours valider d'autre OS et qu'ils ne pouvaient pas garantir que toutes leurs applis fonctionneraient correctement sur autre chose.

Je comprends vos craintes ! Cependant, i vous avez les sources de vos composants tiers, rien n'est insurmentable.

Heureusement, on n'utilise jamais un composant tiers sans en avoir les sources. Ce n'est pas insurmontable, mais la migration va coûter très cher, et mon employeur n'acceptera pas de la financer pour me faire plaisir sur les generics.

Je pense sincèrement que vous passerez plus de temps à ré-ecrire votre application de A à Z en C#.Net (pensez aux composants tiers ou fonctions non dispos sous .Net, voir de repenser à la structure de votre programme) que de modifier votre code pour qu'il compile sous D2009.

J'en ai bien conscience.
Mais on s'interroge déjà très fortement sur la pérénité de Delphi face à .Net ou Java. Ce qui fait que je pense qu'on obtiendra plus facilement un gros budget pour assurer la pérénité du produit, qu'un budget moyen pour pouvoir rester dans l'inconnu un peu plus longtemps.

[gb_68]

Bonjour,

Le moindre bout de code qui utilisait les API Win32 va cesser de fonctionner.

la plupart des API Windows sont Ansi ou Unicode selon qu'elles se termine par A ou W. Sans cet identifiant, c'est la version "en phase avec la compilation" qui est appelée ; en VC++ cela est par exemple réalisé par des macros

Code C++ :

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

1
2
3
4
5
#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

En Delphi, avant la version 2009, les fonctions non post-fixées par A ou W étaient automatiquement liées à la version Ansi

Code :

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

1
2
3
function MessageBox; external user32 name 'MessageBoxA';
function MessageBoxA; external user32 name 'MessageBoxA';
function MessageBoxW; external user32 name 'MessageBoxW';

en 2009, c'est à la version Unicode.
Donc

Code :

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

1
2
3
4
5
var str : string;
begin
   str :=  'Hello World !';
   MessageBox( 0, PChar(str), '', MB_OK );
end;

fonctionne toujours (testé ). Alors à part ceux qui ont utilisé explicitement les versions avec un A, il n'y aura pas tant de problèmes avec les API.

[skywaukers]

Bonsoir,

A priori si, AnsiString à la place de string, AnsiChar à la place de Char, PAnsiChar à la place de PChar...
Mais j'ai qu'en même un doute que ça suffise, il faudrait essayer. Il y a de fortes chances que je me retrouve avec un effet de bord quel que part où il ne faut pas.
Sans compter que je ne peux pas modifier les routines de la VCL pour qu'elles travaillent en Ansi et pas en unicode. Donc il va y avoir des convertions dans tous les sens, et une dégradation des perfs. Ou alors je serais inondé de milliers de warnings (remarque, l'un n'empêche pas l'autre ).

A première vue, pourquoi cela ne fonctionnerait pas ? Fait un test sur une petite appli avec des appels à une api, tu sera vite fixé.

De plus j'ai cru comprendre que maintenant, les applis compilées avec D2009 ne fonctionneront plus avec Win9x car ces OS ne supportent pas l'Unicode. Il y a encore 3 ans, je connaissais de très grosses boîtes (le principal client de mon ancien employeur) qui était toujours sous Win95 et qui ne voulait pas migrer parce qu'ils n'avaient toujours valider d'autre OS et qu'ils ne pouvaient pas garantir que toutes leurs applis fonctionneraient correctement sur autre chose.

oui, effectivement les win9x ne sont pas unicode, mais ce ne sont pas des os d'avenir à mon avis.
Des grosses boites qui fonctionnent sous 98 uniquement ? Ouah, elles font comment leur politiques de sécurité ? Nous nous ne sommes pas ce qu'on peut appeler des avant gardistes, mais ça fait plus de 3 ans qu'on a plus de win9x, et heureusement.

Heureusement, on n'utilise jamais un composant tiers sans en avoir les sources.

Ca c'est une bonne pratique. Et donc tu devrais pouvoir migrer sans trop de problème à mon avis

Mais on s'interroge déjà très fortement sur la pérénité de Delphi face à .Net ou Java. Ce qui fait que je pense qu'on obtiendra plus facilement un gros budget pour assurer la pérénité du produit, qu'un budget moyen pour pouvoir rester dans l'inconnu un peu plus longtemps.

Pour moi c'est simple, Delphi sera perenne tant que Delphi aura des clients. Si tous ses clients s'interrogent sur sa perennité et vont à la concurrence juste par peur de la pérénnité, alors ce sont les clients eux même qui tueront Delphi. Et puis voilà un symptome bien propre à notre communauté je trouve. Pourquoi les communautés de 4D, de Windev, de PHP ne s'inquiètent elle pas de la pérénnité de leur outil ?
Tout simplement parce qu'il y a une place à côté de Java et de .NET. Et aussi parce qu'il y a au moins une place pour un concurrent sérieux à .NET (concurrent nécessaire par ailleurs). Delphi sera celui là si nous lui faisons confiance et si Embarcadero ne la trahit pas.

Et puis la mort de Delphi est annoncée presque depuis sa naissance, et il est toujours là. En plus aujourd'hui il semble sortir de sa léthargie et évolue enfin de nouveau, alors confiance...

Le passage à l'unicode, malgré les contraintes est une bonne chose. A trop regarder derrière Borland s'est laissé dépasser. L'avenir c'est devant, et l'avenir ce n'est plus le 16bits, ce n'est plus win9x non plus, tous les os actuels sont unicode. Alors maintenant il faut pouvoir migrer l'existant, ça c'est sûr, mais si ce n'est qu'un changement de type string en ansistring là où l'unicode n'est pas possible je ne vois pas matière à freiner l'évolution là dedans.

@++
Dany

[Franck SORIANO]

A première vue, pourquoi cela ne fonctionnerait pas ?

gb_68 a répondu à la question. Si je fait un remplacement bête et méchant, je vais me retrouver avec :

Code :

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

1
2
 
MessageBox( 0, PAnsiChar(str), '', MB_OK );

Alors que MessageBox a été modifiée pour travailler avec une chaîne unicode...
Et si je ne fais pas le remplacement, ben je n'utilise pas que des fonctions Win32 qui sont déclarées dans la VCL. Il y en a beaucoup que j'ai importée directement (par exemple, mon article sur ETW) auxquelles je vais fournir des chaines unicodes alors qu'elles attendent de l'Ansi...

Des grosses boites qui fonctionnent sous 98 uniquement ? Ouah, elles font comment leur politiques de sécurité ?

C'est très simple, ce n'est pas leur problème... Pour le client auquel je pense, ce n'est pas une grosse boîte, mais un réseau de franchises. La marque impose un cahier des charges : Pour vendre nos produits, vous devez passer vos commandes avec ce logiciel, nous déclarer vos ventes avec celui là, faire vos retour en garantit avec celui là... Et le tout ne fonctionne que sous Win95.
Donc au final, dans chaque franchise, ils sont obligés de rester sous Win95. Ce qui rien qu'en France représente dans les 2000 magasins...

A la rigueur Win9x, je m'en fiche. Nos clients actuels ont migré depuis quelques temps déjà.

La migration Unicode n'est certainement pas insurmontable. Mais je voulais faire remarquer qu'elle va avoir un coût non négligeable, bien supérieur à la mise à jour des licences.

[Reisubar]

Alors maintenant il faut pouvoir migrer l'existant, ça c'est sûr, mais si ce n'est qu'un changement de type string en ansistring là où l'unicode n'est pas possible je ne vois pas matière à freiner l'évolution là dedans.

Combien d'entre nous écrivent ce genre de code :

Code :

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

1
2
3
4
var
  S: array [0..MAX] of char;
begin
  FonctionModifiantUnPChar(S, SizeOf(S)); //SizeOf à la place de Length()

...ou :

Code :

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

1
2
3
4
5
var
  LStream : TStream;
  S: string;
begin
  LStream.Write(S, Length(S)); //au lieu de Length(S) * SizeOf(Char)

...deux exemples au pif. AMHA, ne sous-estimez pas le coût de la migration vers Unicode et du test de vos applications.

[Telemak]

Bonjour,
au risque d'être hors sujet par rapport au sujet du post....
Mais quand est t'il d'une verstion pour linux..? Il était question à un moment donné, j'ai cru avoir lu par le passé qu'il y aurait un successeur à Kylix .?
a+

[ShaiLeTroll]

Kylix est mort (et enterré), un remplaçant n'est pas exlcu, il faut attendre Octobre pour la nouvelle RoadMap à ce sujet, cela a été Flou durant le Code Way Tour Delphi 2009 du 18 Septembre.

Pour le 0..MAX, moi c'est pire, j'ai souvent omis le SizeOf(S) pour mettre directement un MAX + 1 ou carrément un "GetMem(lpS, MAX + 1);" avec par exemple GetWindowText et GetClassName ... donc le SizeOf à l'avantage de fournir la bonne taille, puisque les APIs par défaut seront Wide ...

Par contre 14 jours, grrr, il pense vraiement que dans les PME\TPE, on a que cela à faire de tester un logiciel, c'est vraiement pas pratique, ... heureusement que Thierry Laborde est là pour nous alonger ... surtout que là, ma boite s'en rend compte du fossé que l'on s'est créé nous même depuis en restant sur D6\D7, et avant de payer des licences, faut voire avant ce que l'on peut et va faire ... le problème c'est que l'on a pas évolué, et donc que l'on perd de la maîtrise à fur et à mesure de nos outils ...

Delphi et Windev, lol, en 2002, Windev 7.5 apportait enfin les Anchors déjà existant depuis Delphi 4 (1998), il apportait aussi enfin des fonctions TCP\IP officielle (après les versions 5.5 Beta de Juin 2002), ce qui existait en Delphi depuis très longtemps (ScktComp), eh bien, si aujourd'hui, l'IDE Delphi parait en retard (est-ce qu'il est d'ailleurs ?), ce n'est qu'un aléa de la vie d'un logiciel, ... maintenant ça c'est n'est QUE pour le point de vue IDE, point de vue du langage, il n'y a pas photos, Puissance, Efficacité, Robutesse, Potentialité, Delphi est TRES TRES loin devant ...

[octal]

Je travaille actuellement avec D2007

J'ai installé, pour la tester la trial de D2009 sur un autre poste.
L'objectif est de tester mon code avec le nouveau compilateur (Unicode..)

Par curiosité, j'ai ouvert la démo du nouveau composant ruban, je suis assez
déçu :
- Flickering important au redimensionnement.
- Flickering léger même lorsque on promène simplement la souris d'un label à l'autre.
- Bug si on clique droit pour personnaliser la barre d'outils du ruban : quand on ressort les composants du ruban ruban restent désactivés : la barre devient alors inutilisable.

j'ai même essayé de mettre la form de la démo en doubleBuffering : ca ne change rien. J'ai activé Aero (au cas où..) : ca ne change rien.

Vous constatez les mêmes problèmes ou bien est ce moi qui ait un problème sur ma config de test ?

Bonjour,
je confirme. J'ai installé D2009 et je fais aussi des tests dessus en vue de migration.

- L'IDE est vraiment plus rapide que dans la D2007.

- Plein de nouveaux petits composants, genre butonEdit, ... sympa, ça évite de devoir installer certain petit composants tierces juste pour ce genre de bidules.

- Gestion de l'Unicode en Natif. Les composants que j'ai écris moi même sont tous devenu Unicode Enabled comme par magie (c'est des composant d'interface GUI, donc pas eu de pb de manip de chaine unicode).

- Le ruban est une HORREUR. Vraiment déguelasse. Scintillement horrible, redimensionnement pas terrible, puis créez une nouvelle appli, glissez le ruban dessus, compilez (sans rien mettre), et hop votre exe a environ 1.7Mo ... terrible leur ruban. Ils auraient pu simplement faire l'effort et racheter une license du ruban de DevExpress (franchement le meilleur digne de ce nom en composant vcl ruban).

- Les génériques en Win32, cela faisait bien longtemps que j'attendais cela sous Delphi X86 natif. C'est fait et c'est un régal (surtout pour les TList typées).

Bref, j'utiliserais surement pas leur ruban (la honte), mais je passerai bien sous D2009.

Cordialement
octal

[Franck SORIANO]

Code :

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

1
2
3
4
5
var
  LStream : TStream;
  S: string;
begin
  LStream.Write(S, Length(S)); //au lieu de Length(S) * SizeOf(Char)

Cet exemple m'inspire encore un autre type de problème. Imaginons que tout fonctionne à la perfection, et que ce soit le bon nombre d'octets qui soient enregistrés dans le fichier (parce qu'on a corrigé le code).
Le fichier avait une spécification, qui prévoyait un certain format, avec des chaînes Ansi. Si on recompile en Unicode, on change implicitement le format du fichier.
L'appli n'est plus compatible avec les anciens fichiers déjà écrits, et elle ne génère plus des fichiers conformes aux spécifications puisque la chaîne est devenue unicode...

[Laurent Dardenne]

L'appli n'est plus compatible avec les anciens fichiers déjà écrits, et elle ne génère plus des fichiers conformes aux spécifications puisque la chaîne est devenue unicode...

Bravo ! C'est bien vu.
Ce qui est regrettable c'est qu'il faille faire cette étude en lieu et place de l'éditeur