[Débat] Votre avis sur Delphi 2009 en version Trial

[Reisubar]

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.

Néanmoins, normalement, les méthodes SaveToFile() ont un paramètre optionnel qui permet de choisir l'encodage d'un fichier (ce qui permettrait dans certains cas de limiter la casse). Ce que j'aimerais savoir c'est : si on ne précise pas cet encodage (par exemple, parce qu'on recompile un projet D2007 sans modifier le code), qu'est ce qui se passe ?

1. Le flux est conservé en ANSI (avantage : compatibilité descendante)
2. Le flux est sauvé au même format qu'il a été lu, s'il a été lu depuis un fichier par exemple (avantage : "auto-support" d'Unicode sans changer son code)
3. Le flux est sauvé dans un format Unicode

Si quelqu'un a l'occasion de tester...

[skywaukers]

Bonjour,

Envoyé par Reisubar

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

Oui, complètement d'accord là dessus !! aucune migration d'ailleurs ne doit se faire à la légère, il faut à mon avis toujours repasser tous les jeux de tests et s'assurer que rien n'a régressé, et qu'aucun nouveau problème liés aux modifications de la nouvelle version n'est apparu.
Ce que je voulais dire, mais je me trompe peut-être, c'est que de plus en plus l'unicode se généralisera et qu'à un moment ou un autre il faudra se faire violence.

@++
Dany

[ShaiLeTroll]

Et pour les Variants (TVarData) et les const (TVarRec), c'était du AnsiString ... donc ça va aussi changé ... j'ai du faire quelque cast sauvage de VString (qui est un pointer) ...

[Andnotor]

Une chose dont je suis surpris est que personne n’invoque la gestion des fichiers png largement médiatisée !

A part le TImage qui semble le gérer correctement, le TImageList ignore purement et simplement le canal alpha et ne gère finalement qu’un bitmap 24 bits ! Le fond noir rend les images inutilisables !!!

Triste pour un composant que l’on retrouve dans tous les autres…

Quant aux Controls avec une propriété Glyph. Il n’accepte toujours que des bmp.

Personnellement, J’aime bien l’édition des ressources. Un même utilitaire pour l’édition d’un manifest Vista ou l’ajout de quelques paramètres dans les propriétés de l’application aurait aussi été sympa !

Quant à l’unicode, il est indispensable.

Pour les problèmes de migration, je pense que malheureusement, beaucoup de gens ne sont pas assez stricts dans leur codage (ou n’ont peu être pas le temps de l’être…) ce qui rend la conversion plus difficile!

Pour ma part et pour l’instant je ne pense pas acheter D2009… Windows 7 arrive avec sont lots de nouveautés (multi-touch entre autre !) qui ne seront de toute façon pas implémentés et les composants TMS font parfaitement l’affaire en unicode. Peut-être D2010.

[ShaiLeTroll]

Envoyé par Andnotor

je pense que malheureusement, beaucoup de gens ne sont pas assez stricts dans leur codage

Ou des gens ont dû faire des développements pointus (manipulation de chaine et de la mémoire) et pensait que certaines choses comme la taille d'un char était immuable et donc égale à 1, ... il est évident que si l'on ne manipule pas les chaines (découpage, parsing, analyse syntaxique, streaming, ...) massivement dans une application de gestion banale, on a pas de problème de migration ...

Autre exemple, les DLL, cette qui ne sont pas de Windows, et bien, ces DLL restent ANSI, donc faut gentillement remplacer les PChar par des PAnsiChar, les string par AnsiString ... mais aussi les Char par AnsiChar, car justement, si l'on a bien fait son travail en étant strict et rigoureux en utilisant un SizeOf(Char), et bien, dans le header, faut tout remplacer en SizeOf(AnsiChar) ... Donc en fait, parfois le laxisme à du bon ... c'est pas dur (un remplacer tout ou un les machins de refactoring que je ne connais pas), c'est juste pénible ...

Ou encore, l'échange de Record via TCP\IP, genre des array of char, idem, le programme en face, il a pas changé lui, donc allez faut modifier tout son code, ... c'est le même problème que pour les fichiers binaires structurés, ...

En fait, c'est l'inverse des API Windows, si l'on bénéficie par défaut du Wide pour les API (ce qui est bien), pour les API Externes, ça se complique ...

Sinon pour le PNGImage, ben, c'est le même que MakePNG de la JVCL, ça ne fonctionnait correctement que dans le TImage ... je ne peux pas comparer, j'ai une version de 2003, il y a du avoir des nouveautés en 5 ans ...

[Andnotor]

Je n'ai pas dit que la migration serait du 100% à la 1er compilation

Tes remarques pour les DLL ou TCP sont corrects à partir du moment ou il s'agit d'applications tiers... ou d'applications que tu ne comptes pas recompiler pour le moment! Sinon je ne vois pas le problème sur la taille des structures.

Quant à concidérer que la taille d'un char serait imuable, c'est exactement les erreurs auquelles je pensait.
Combien de personne déclare une variable FileName en string alors qu'elle devrait être en TFileName? Bien sûr qu'actuellement le TFileName est un string, mais pour combien de temps?

J'ai personnellement commencé à programmer en Turbo Pascal (5 ou 6...) et à l'époque Delphi 2 (je crois ), les mêmes questions se posaient alors pour le passage des ShortString en chaînes longues....

[ShaiLeTroll]

Je parlais évidemment de DLL Externes utilisées dans les projets, par exemple des Drivers DB comme Appolo ou LibMySQL.dll, je pense à des DLL gérant du matériel, je pense à de l'inter-opérabilité entre programmes distants entre sociétés partenaires, je pense a des programmes écrits dans un autre langage, des Reader\Writer de fichiers binaires ... pour ma part, j'ai beaucoup de programme dans cette situation, ... tout le monde ne travaille pas en autarcie ... évidemment, une structure utilisée juste pour le stockage de données en mémoire, cet évolution n'aura aucun impact, dans beaucoup d'autres situation, cela à un impact majeur...


Pour le FileName, effectivement, c'est bien vu, mais regardons honnêtement les fonctions fichiers de SysUtils de Delphi, et bien tous paramètres nom de fichier sont passés en string, donc Borland ne code pas aussi strict que ça alors que le type TFileName est défini quasiment dès le début de l'unité, ... dans mon D7, je vois 107 occurences de TFileName, lol, c'est quoi 0.01% des string FileName, ...

Pour le passage de la ShortString à la string, je n'ai pas connu, j'ignore comment cela c'est passé, mais ce passage ne touchait pas au type PChar, hors, ce n'est pas le type string qui me pose problème, mais bel et bien le type PChar ...

[octal]

Envoyé par Andnotor

Une chose dont je suis surpris est que personne n’invoque la gestion des fichiers png largement médiatisée !

A part le TImage qui semble le gérer correctement, le TImageList ignore purement et simplement le canal alpha et ne gère finalement qu’un bitmap 24 bits ! Le fond noir rend les images inutilisables !!!

Triste pour un composant que l’on retrouve dans tous les autres…

Le TImageList les gère correctement. Il suffit de Changer (renseigner correctement) les propriétés ColorDepth et Transparency du TImageList !

Cordialement

[Andnotor]

Oups! Merci Octal, tu as tout à fait raison

[philgeorges]

Personnellement, je ne développe que sous Win32 et je trouve cet environnement beaucoup trop lourd, trop long à charger, trop lent... Ne serait-il pas possible de penser au même style que delphi 7, remanié et mis à jour niveau VCL ? Pourquoi avoir besoin d'un espace disque si élevé et pas toujours justifié dans le cadre de windows 32 bits / 64 bits ?

[ShaiLeTroll]

Envoyé par Andnotor

Oups! Merci Octal, tu as tout à fait raison

Euh, le sujet est vaste Andnotor, Octal avait raison sur quoi, pour que l'on se comprenne

[michel_ballasse]

Tout chaud tout bouillant Stéph..............
Tu nous casses les "beeeep" avec tes PCHar
Non je rigole. Mais tu as raison.

Plaisanterie mise à part, pour avoir tester la version 2009, hormis le support de l'unicode (désolé steph, masi il faut tout emême le signaler), il n'y a pas de quoi déplacer des montagnes.

Donc pour moi, en régie chez un gros industriel français qui fabrique du verre (on n'a pas le droit de faire de pub il me semble...) c'est Wait and Wait......
On reste en Delphi 7.

OK je sors......

[ShaiLeTroll]

Oh, Karibou, mais j'aime mes "beeeep" de PChar

Sinon, philgeorges, moi, je suis encore en D6 et D7 () , c'est juste que pour moi, Delphi 2009 et l'UniCode, c'est une énorme avancée (la seule de 2009 en fait), et c'est un cap à ne surtout pas louper, en terme de compétence professionnelle (j'ai à peine vu D8 et Turbo Delphi), c'est crucial personnellement, mais pour ma boite, cela n'a quasiment aucun intérêt parce que de toute façon, y passera jamais, trop de lib externe, trop de vieux code qui se traine depuis D4, manque de spécif, je vais reprendre le bon vieux concept du TPCM comme l'a dit Pleinpopossum : "touche pas, ça marche" qui ressemble au "Wait and Wait" non ?

[ShaiLeTroll]

Ah, ben c'est bon à savoir, en D7, je n'ai pas ColorDepth (on peut tout suite imaginer une liaison avec PixelFormat), je vais en avoir des choses à découvrir ... 14 jours ça ne suffira jamais !

[VLDG]

Moi je pense a ceux qui développent pour des pays de l'est comme la Pologne, la Russie... avec des alphabets un peu différent et je me dis quelle chance ce Delphi 2009 !

Je pense personnellement que la conversion de l'application doit être assez simple quand on utilise des composants de renommé (TMS, devexpress, fast report...)
Mais par contre pour les bases de données, si on était pas en Unicode il risque d'y avoir quelques petits soucis et c'est quand même ça le plus important : les données !

[Andnotor]

Je vais juste un peu nuancer ton commentaire VLDG.

La saisie de texte en russe, en grec ou toutes autres langues de l'ouest n'a jamais posé de problème. Les codes de caractères utilisés (la table ansi) dépendent du clavier et de la langue chargés.

Les problèmes surviennent losqu'on veut mixer ces langues ou visualiser quelque chose provennent d'une autre région linguistique alors que notre système n'est pas setté pour.

A noter que l'unicode ne résout pas tout. La langue devra de toute façon être disponible au niveau du système opératif.

[Franck SORIANO]

Envoyé par VLDG

Mais par contre pour les bases de données, si on était pas en Unicode il risque d'y avoir quelques petits soucis et c'est quand même ça le plus important : les données !

En effet, une appli unicode avec une base ansi ça ne sert pas à grand chose... On en revient à : la migration unicode ne se résume pas à recompiler...
Sans compter que l'unicode est loin de résoudre tous les problèmes qu'on rencontre avec les jeux de caractères.

Quelqu'un a déjà essayé de localiser une appli pour la Turquie ? Avec le coup de leur i dont la majuscule n'est pas I, il y a de quoi planter une appli même Unicode si la base n'était pas case sensitive au niveau de sa structure.

[Suryavarman]

Ma conclusion Delphi 2009 c'est juste pour migrer vers l'unicode.

Les génériques...sont ...hummm dit avec gentillesse très simplets.
essayez de faire une procédure générique en dehors d'une classe...bein oui on peut pas, il n'y a pas moyen de déclarer un type générique en dehors d'une structure (interface, classe et record). Vous êtes obligé de créer une classe avec la procédure en t'en que "class procedure" pour feinter.

Les méthodes anonymes avec générique ça fonctionne , enfin faut faire gaffe avec les overload, je me suis retrouver avec une erreur interne, Méthodes anonymes c'est pas encore au point (voir mon code ci-dessous ).

Quand Delphi aura une spécification mature et non juste tape à l'œil, il sera intéressant de dépenser de l'argent pour une nouvelle version.


Si ça intéresse et pour pouvoir en discuter voici le code de mon petit projet test :
Déclaration du patron d'interface et de classe

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
 
unit Genereic_Array;
 
interface
 
type
  TProcArray<T> = procedure( aItem : T ) ;
  TProcObjArray<T> = procedure( aItem : T ) of Object ;
  TProcAnoArray<T> = reference to procedure( aItem : T ) ;
 
  IArray<T> = interface
  ['{4A0DA6EB-9B6B-4787-BA69-831E0ED49023}']
 
    function  push_back( aItem : T ) : integer ;
    function  pop_back() : T ;
    function  size() : integer ;
    procedure clear() ;
    function  empty() : boolean ;
 
    function GetValue(aIndex: integer): T;
    procedure SetValue(aIndex: integer; const Value: T);
    property  items[aIndex : integer] : T read GetValue write SetValue; default ;
 
  end;
 
  Gen_Array<T> = class( TInterfacedObject, IArray<T> )
 
    private
      function TestIndex( aIndex : integer ) : boolean ;
 
    protected
      FItems : array of T ;
 
      function GetValue(aIndex: integer): T;
      procedure SetValue(aIndex: integer; const Value: T);
 
    public
      function  push_back( aItem : T ) : integer ;
      function  pop_back() : T ;
      function  size() : integer ;
      procedure clear() ;
      function  empty() : boolean ;
 
  end;
 
 
  Gen_Algorithme<T> = class
 
    class procedure foreach( aArray : IArray<T>; aProc : TProcArray<T> ) ; overload;
    class procedure foreach( aArray : IArray<T>; aProc : TProcObjArray<T> ) ; overload;
    //class procedure foreach( aArray : IArray<T>; aProc : TProcAnoArray<T> ) ; overload;
    // même si on ne l'utilise pas, elle provoque des erreurs internes à cause de l'overload
    // méthode anonymes...c'est pas encore ça.
    // mais elle fonctionne bien si il n'y a que elle
 
  end;
 
  Gen_AlgorithmeAnonyme<T> = class
 
    class procedure foreach( aArray : IArray<T>; aProc : TProcAnoArray<T> ) ;
 
  end;
 
 
implementation
 
{ Gen_Array<T> }
 
procedure Gen_Array<T>.clear;
begin
 
  while not empty do
    pop_back ;
 
end;
 
function Gen_Array<T>.empty: boolean;
begin
 
   result := length( FItems ) = 0 ;
 
end;
 
function Gen_Array<T>.GetValue(aIndex: integer): T;
var  aItem : T ;
 
begin
 
  if TestIndex( aIndex ) then begin
 
    result := FItems[aIndex]
 
  end else begin
 
    result := aItem ;
 
  end;
 
end;
 
function Gen_Array<T>.pop_back: T;
begin
 
   result := FItems[size - 1] ;
   setlength(FItems, size - 1 ) ;
 
end;
 
function Gen_Array<T>.push_back(aItem : T): integer;
begin
 
   setlength(FItems, size + 1 ) ;
   result := size-1 ;
   FItems[result] := aItem ;
 
end;
 
procedure Gen_Array<T>.SetValue(aIndex: integer; const Value: T);
begin
 
  if TestIndex( aIndex ) then
    FItems[aIndex] := Value ;
 
end;
 
function Gen_Array<T>.size(): integer;
begin
 
  result := length(FItems) ;
 
end;
 
function Gen_Array<T>.TestIndex(aIndex: integer): boolean;
begin
 
   result := ( aIndex < size ) and ( aIndex > -1 ) ;
 
end;
 
 
{ Gen_Algorithme<T> }
 
 
class procedure Gen_Algorithme<T>.foreach( aArray : IArray<T>; aProc : TProcArray<T> ) ;
var  i : integer ;
 
begin
 
  for i := 0 to aArray.size - 1 do begin
 
     aProc( aArray[i] ) ;
 
  end;
 
end;
 
class procedure Gen_Algorithme<T>.foreach(aArray: IArray<T>; aProc: TProcObjArray<T>);
var  i : integer ;
 
begin
 
  for i := 0 to aArray.size - 1 do begin
 
     aProc( aArray[i] ) ;
 
  end;
 
end;
 
 
(*
class procedure Gen_Algorithme<T>.foreach(aArray: IArray<T>;aProc: TProcAnoArray<T>);
var  i : integer ;
 
begin
 
  for i := 0 to aArray.size - 1 do begin
 
     aProc( aArray[i] ) ;
 
  end;
 
end;
//*)
 
{ Gen_AlgorithmeAnonyme<T> }
 
class procedure Gen_AlgorithmeAnonyme<T>.foreach(aArray: IArray<T>; aProc: TProcAnoArray<T>);
var  i : integer ;
 
begin
 
  for i := 0 to aArray.size - 1 do begin
 
     aProc( aArray[i] ) ;
 
  end;
 
end;
 
end.

Utilisation du générique

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
 
unit Unidoce_01;
 
interface
 
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, Genereic_Array;
 
type
 
  TFormTestUnicode = class(TForm)
    Edit1: TEdit;
    Button1: TButton;
    Button2: TButton;
    procedure FormCreate(Sender: TObject);
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
 
  private
 
  public
    { Déclarations publiques }
  end;
 
  procedure WriteLn( aInt : integer ) ; overload;
  procedure WriteLn( aStr : string  ) ; overload;
  procedure WriteLn( aObj : TObject ) ; overload;
 
var
  FormTestUnicode: TFormTestUnicode;
 
implementation
 
{$R *.dfm}
 
procedure TFormTestUnicode.Button1Click(Sender: TObject);
begin
  writeln( Edit1.Text ) ;
end;
 
procedure TFormTestUnicode.Button2Click(Sender: TObject);
var  aArrayInteger : IArray<integer> ;
     aArrayString  : IArray<string> ;
     aArrayObject  : IArray<TObject> ;
 
begin
 
  aArrayInteger := Gen_Array<integer>.Create ;
  aArrayString  := Gen_Array<string>.Create ;
  aArrayObject  := Gen_Array<TObject>.Create ;
 
  aArrayInteger.push_back( 1 ) ;
  aArrayInteger.push_back( 2 ) ;
  aArrayInteger.push_back( 3 ) ;
  aArrayString.push_back( Sender.ClassName ) ;
  aArrayString.push_back( ' toto' ) ;
  aArrayObject.push_back( Sender ) ;
  aArrayObject.push_back( Edit1 ) ;
 
  Gen_Algorithme<integer>.foreach( aArrayInteger, WriteLn ) ;
  Gen_Algorithme<string>.foreach( aArrayString, WriteLn ) ;
  Gen_Algorithme<TObject>.foreach( aArrayObject,  writeln ) ;
 
  writeln( 'Anonyme Test :' ) ;
 
  Gen_AlgorithmeAnonyme<integer>.foreach( aArrayInteger, procedure ( aInt : integer )
  begin
 
    writeln( IntToStr( aInt ) ) ;
 
  end ) ;
 
  Gen_AlgorithmeAnonyme<string>.foreach( aArrayString, procedure ( aStr : string  )
  begin
 
    system.Writeln( aStr ) ;
 
  end ) ;
 
  Gen_AlgorithmeAnonyme<TObject>.foreach( aArrayObject, procedure ( aObj : TObject )
  begin
 
    writeln( aObj.ClassName ) ;
 
  end ) ;
 
end;
 
procedure TFormTestUnicode.FormCreate(Sender: TObject);
begin
 
  AllocConsole ;
 
  Edit1.Text := #$904D ;
  Caption := Caption + ' ' + #$904D + #$5208 ;
 
end;
 
procedure WriteLn( aInt : integer ) ; overload;
begin
 
  writeln( IntToStr( aInt ) ) ;
 
end;
 
procedure WriteLn( aStr : string  ) ; overload;
begin
 
  system.Writeln( aStr ) ;
 
end;
 
procedure WriteLn( aObj : TObject ) ; overload;
begin
 
  writeln( aObj.ClassName ) ;
 
end;
 
 
end.

[colfire_dev]

Moi, je developpe avec delphi depuis la version 1. Je trouve qu'il est toujours très en retard par apport à visualstudio, moins de composant et la leurs qualités laisse à desirer par rapport à visualstudio surtout avec la version 2008.
En comparant visual sutio 2008 et delphi 2009 c'est un grand ecart.
En base de données il y a pas d'amélioration.
Pour conclure à part le composant ruban et l'integration du format PNG, je vois rien de tetant.

[VLDG]

Envoyé par Andnotor

Je vais juste un peu nuancer ton commentaire VLDG.
A noter que l'unicode ne résout pas tout.

si un outil résolvait tout : que ferions nous !