Discussion :

[vanquish]

Bonjour,

Pour ceux qui ont testé Delphi 2009.

Existe-t-il une directive de rétro-compatibilité pour dire de ne pas utiliser unicode par défaut et assurer ainsi la rétro-compatibilité.

Jusqu'ici, chaque fois qu'il y avait un changement, il y avait une directive de compilation permettant d'assurer la rétro-compatibilité.

Il semble que, cette fois et pour ce point ce ne soit pas le cas !!
(il est vrai qu'il aurait fallut fournir une double VCL)

Cela ne me poserait pas trop de problème s'il n'y avait que mon source à moi.

Mais j'utilise bien une cinquantaine de composants qui doivent représenter des centaines de milliers de lignes de code. Je n'ai ni le temps, ni la compétence de les mettre à niveau. Donc si l'auteur original ne le fait pas (beaucoup ont déjà quitté le navire pour dotnet) ....

Quelqu'un peut affirmer ou infirmer cette absence.

[ShaiLeTroll]

Voir la réponse de Reisubar sur le sujet Stratégie suite à changement d'OS et décisions à prendre

Durant le Code Way Tour, on a aperçu une directive de compilation genre {IFDEF UNICODE} mais elle n'est là que pour la transition du CodeGear de Delphi lui-même !
Je n'ai qu'une version Trial, donc je n'ai pas les sources pascal comme j'en ai l'habitude avec D7 en version pro, ...

Si tu as de la chance, tes composants fonctionneront ... sauf si il y a de l'utilisation de PChar à la sauvage (GetMem, CopyMemory, ... sans le SizeOf(Char) souvent remplacé par 1 pensant que cela ne changerait jamais)

Si tu n'as pas de chance : Dis adieu à tes composants ANSI !

Moi, je n'en ai pas, j'ai plutôt dans les 5 millions de ligne de code de composants externe (les maintenus : Jedi, TMS, ReportBuilder\InfoPower\ExtraDevices, SecureBlackBox, tous ne sont pas encore prêtes, et je passe les non maintenus comme HyperStr), et l'on sait que les versions récentes de certaines composants ne sont plus compatibles avec nos applications, alors il faudrait déjà corriger les bugs de nos applis avec les dernières versions D7 des composants (voire même D2007) puis ensuite passer à D2009 ...

[VLDG]

Regarde un peu ici :

The (unofficial) Unicode Switch is now available
http://andy.jgknet.de/blog/?p=322

[ShaiLeTroll]

C'est intéressant VLDG, n'aurais-ton pas des mauvaises surprises en appelant les API Windows, il ne tenterait pas un appel à une version W en lui passant du ANSI ?

[Paul TOTH]

tite question, si je place en début d'une unité commune à tout mon projet la ligne suivante :

Code :

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

1
2
3
 
type
 string=AnsiString;

est-ce que cela fonctionne ?

[ero-sennin]

Salut Paul.

Non, on ne peut pas, et pour cause :

[DCC Erreur] Unit1.pas(10): E2029 Identificateur attendu(e) mais 'STRING' trouvé(e)

[VLDG]

C'est intéressant VLDG, n'aurais-ton pas des mauvaises surprises en appelant les API Windows, il ne tenterait pas un appel à une version W en lui passant du ANSI ?

j'ai juste vu cela il y a quelques jours. Je n'ai pas eu le temps d'approfondir et je n'ai pas Delphi 2009 aussi

[vanquish]

Merci (un peu tardif, mais j'ai été éloigné du site quelques temps) de vos réponses.

Il existe un switch {$H}, mais il est inutilisable en pratique, car la VCL est en unicode. On ne peut donc utiliser le switch pour tout un projet/composant.

Si tu as de la chance, tes composants fonctionneront ...

C'est tout le problème.

Je ne suis pas trop inquiet pour certains, un peu plus pour d'autres.

Les auteurs de ZeosLib annoncent un gros délais.

Je n'ai pas de temps à perdre à tester tout cela (installation de Delphi sur machine de test, passage composant par composant, achat d'upgrade etc..)

D'autant plus que pour moi qui fait du franco/français le gain est nul, sans parler du risque d'introduire des bugs à des endroits où il n'y en avait pas (y compris dans les librairies tiers, payante ou pas, et qui n'en sont déjà pas exempt à la base).

Offrir la possibilité d'Unicode était indispensable (XML, WebServices, certains SGBD).
Le mettre en natif, probablement une erreur.
La communauté Delphi glisse de plus en plus vers DotNet.
Si la compatibilité ascendante n'est plus assurée, même pour du pur Win32, je ne suis pas certain que cela n'accélère pas encore les choses.

La lecture des forums codegear est assez instructive sur l'état d'esprit de nombreux utilisateurs : ils ne passeront à D2009 que contraint et forcé.
Je trouvais déjà que ça sentait le sapin ....

Les académiques expliquent qu'il ne faut pas regarder en arrière et qu'aujourd'hui unicode est indispensable. Les pragmatiques ne voient pas pourquoi perdre du temps (et de l'argent) à implémenter une fonction dont ni eux, ni leurs utilisateurs n'ont besoins.

exemple de commentaires trouvés :

Customer: I need a water jug.
Manufacturer: We considered a jug that could be used to carry every kind of liquid, water, acid, liquid oxygen, you name it. Unfortunately, it turned out that it couldn't be done.
Customer: OK, but I just want it to hold water...
Manufacturer: Sorry, the decision was made, there is no going back!

Unicode doit préparer à Win64. Sauf que toutes les nouvelles API (WCF, WPF ..) sont très liées à DotNet. Sincèrement, je ne me vois pas démarrer un projet Win64 (ou tout nouveau projet d'envergure) en autre chose que C#.

Cordialement.

[ShaiLeTroll]

La communauté Delphi glisse de plus en plus vers DotNet.

Il ne faut pas tout mélanger, le support de l'UniCode arrive bien tard pour la VCL, il est supporté par Windows depuis au moins Window 2000 (NT4 et même Win98 je crois) et depuis Delphi 5 (peut-être même avant) tu as les versions Wide des fonctions API de Windows ...
Il ne font rattraper qu'un grand retard ...

La lecture des forums codegear est assez instructive sur l'état d'esprit de nombreux utilisateurs : ils ne passeront à D2009 que contraint et forcé.
Je trouvais déjà que ça sentait le sapin .....

Oh là ! Moi, j'adorais y passer (D7 à D2009), j'ai plus que SecureBlackBox qui devrait livrer sa release UniCode ... les autres libs seront abandonnés. Le Gros du travail sera sur la lib interne de mon employeur, on s'est laissé dépassé depuis trop longtemps, il faut y passer, faut juste en avoir la volonté (les moyens on les a, faut juste aussi se les donner).

Après pour la suite, il faut voir ce que cela donne, comment va se poursuivre la gamme Win32 dans l'environnement Windows, et là ce n'est pas Delphi le problème mais MicroSoft ... pourrons-t-il oser de supprimer le Win32 dans le prochain OS rendant toutes les anciennes applications non compatible ...
Autre Question est-ce que le multi-plateforme ne sera géré que via Prism.NET ? ou il y a des idées pour faire un Delphi pour Linux ? (le problème c'est la gueule du code ? jouer avec les directives ou VCL system plus poussé donc finalement un concurrent du .NET, donc trop couteux en développant pour CodeGear) ...

Par contre, pour tous nouveaux projets, c'est un framework interne en PHP qui est choisi, donc un langage totalement orienté vers la solution "NO .NET" ... seul les applications de Compta\RH resteront encore pendant 10 ans en Delphi car applicatif non connecté au web sur des vieux windows (en afrique et asie pour les ONG)

[Andnotor]

Cela m'étonnerais que Microsoft supprime Win32 avant longtemps. Il viennent juste de l'introduire dans Windows Mobile 6.

[vanquish]

Bonjour,

Cela m'étonnerais que Microsoft supprime Win32 avant longtemps.

Entièrement d'accord avec toi.
Win32 sera encore supporté très longtemps. Mais il n'évoluera plus.

Je ne veux donc pas me laisser enfermer dans Win32.
La nouvelle API que Microsoft déploie partout c'est .Net : pour client lourd (Winform, WPF), pour le Web (Asp.Net), Web riche (Silverlight), pour les mobiles (Compact Framework) et même pour l'embarqué ( µ Framework).

Donc je ne vois pas l'intérêt de démarrer un nouveau projet en Delphi.VCL, voir en Delphi tout court. Delphi m'a attiré par sont Framework (VCL dont le papa est aussi celui de .Net) et non pour son langage (Pascal - même s'il reste mon préféré). L'intérêt de Prism me parait très limité. Le passage Delphi/C# n'est pas si compliqué, sans parler du risque de faible pérénité du produit (il n'y a qu'à voir où en est Kylix).

Par contre, pour tous nouveaux projets, c'est un framework interne en PHP qui est choisi

On en est donc au même point.
On ne démarre rien de neuf avec Delphi. D'où le peu d'envie pour moi de faire un lourd investissement dans un passage vers D2009, même si j'aimerais bien profiter des nouveautés de l'EDI, de certains nouveaux composants et de certaines extensions de langage.

Il ne font rattraper qu'un grand retard ...

Peut-être trop tard. Il y a 3 ou 4 ans, j'aurais probablement fait l'effort (sans même me poser la question). Aujourd'hui ....

Cordialement,