Discussion :

[Roland Chastain]

Bonjour !

Je souhaiterais porter vers XE2 un projet Delphi 7 qui utilise l'unité WinGraph.

Apparemment, il n'y a qu'une ligne dans l'unité qui pose vraiment problème :

[DCC Erreur] wingraph.pas(2620): E2010 Types incompatibles : 'AnsiChar' et 'Char'

Voici la ligne :

Code :

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

  fontname[0]:=Chr(len-1);

J'ai essayé bêtement de remplacer partout Char par AnsiChar et PChar par PAnsiChar, mais ça n'a pas fonctionné.

Quelqu'un pourrait-il me montrer la modification à faire ?

Je joins le fichier source de l'unité WinGraph avec un exemple.

[tourlourou]

J'essayerais volontiers

Code :

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

1
2
3
4
5
6
7
8
9
procedure GetFontSettings(out fontname:shortstring; out width,height:word; out ttfont:boolean);
var lptm: TEXTMETRIC;
    len : longint;
begin
  len:=GetTextFace(grWindow,255,nil);
 // fontname[0]:=Chr(len-1);  
  Byte(fontname[0]) := len-1;
// ou
  PByte(@fontname[0])^ := len-1;

ou encore

Code :

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

1
2
3
4
5
6
7
8
procedure GetFontSettings(out fontname:shortstring; out width,height:word; out ttfont:boolean);
var lptm: TEXTMETRIC;
    len : longint;
  ShortStringLength: Byte; absolute fontname[0];   
begin
  len:=GetTextFace(grWindow,255,nil);
 // fontname[0]:=Chr(len-1);  
   ShortStringLength := len-1;

[Roland Chastain]

Merci pour la réponse et les exemples.

D'après le test que je viens de faire, les deux premières modifications font effectivement disparaître le message d'erreur. Mais le programme ne fonctionne pas : aucune fenêtre ne s'ouvre.

[Paul TOTH]

Bonjour,

dans le cas présent c'est une erreur de vouloir s'accrocher aux AnsiString, Delphi facilite la tâche pour le passage en Unicode.

au lieu d'utiliser des shortstring, il vaut mieux utiliser des string car toute l'API déclarée dans XE2 s'attend à avoir des "WideString", ce que sont les string.

en effet une bonne partie de l'API Windows est dupliqué en version Ansi et Wide (exemple TextOutA et TextOutW) avant Delphi 2009 la fonction TextOut était un alias de TextOutA en ANSI, depuis Delphi 2009 c'est un alias de TextOutW en WideString. Si tu veux une unité WinGraph Ansi il faut donc utiliser les fonctions avec le suffix "A" pour forcer un appel Ansi.

d'autre part l'élément 0 n'existe plus sur un string, on utilisera donc SetLength()

voici quelques modifications suffisante pour que ton HelloWorld fonctionne sous XE2.

wingraph.zip

[Roland Chastain]

Merci Paul pour les explications et le code.

Je crois qu'il sera peut-être plus sage pour le moment de continuer mes projets WinGraph avec Delphi 7, en attendant de voir plus clair dans cette question des différents types de chaîne.

Soit dit en passant, je n'ai pas encore compris pourquoi il y a d'anciens programmes qui se compilent sans problème sous XE2, et d'autres non. Or j'aimerais bien passer à XE2, mais à condition de pouvoir reprendre assez facilement d'anciens programmes. Et je voudrais bien aussi, dans la mesure du possible, que quelqu'un qui utilise une autre version de Delphi puisse compiler le programme que j'écris.

Quelqu'un a-t-il déjà écrit un Guide pratique du Delphi universel ?

[Roland Chastain]

@Paul TOTH

Je viens de m'apercevoir que l'unité WinGraph modifiée fonctionne toujours sous Delphi 7.

Il faut que je comprenne ce que tu as fait, d'autant qu'il y a encore une ou deux choses à modifier sans parler des deux autres unités du package. Je vais voir si je m'en sors tout seul.

[tourlourou]

Les ShortString sont un type archaïque de chaînes d'AnsiChar, de taille maximale fixée à 255 caractères, occupant 256 caractères accessibles comme un tableau, celui d'indice 0 contenant en fait la longueur de la chaîne stockée.

Les String sont des chaînes dynamiques de caractères, stockant à part la longueur, et terminées par un #0 invisible pour le programmeur, facilitant en interne les conversions string/PChar.

En transformant une ShortString en String, Paul Toth a levé le souci du transtypage pour l'affectation de sa longueur, réalisé par SetLength().

Et comme Delphi 7 connaît aussi les String...

[Roland Chastain]

Les ShortString sont un type archaïque de chaînes d'AnsiChar, de taille maximale fixée à 255 caractères, occupant 256 caractères accessibles comme un tableau, celui d'indice 0 contenant en fait la longueur de la chaîne stockée.

Les String sont des chaînes dynamiques de caractères, stockant à part la longueur, et terminées par un #0 invisible pour le programmeur, facilitant en interne les conversions string/PChar.

En transformant une ShortString en String, Paul Toth a levé le souci du transtypage pour l'affectation de sa longueur, réalisé par SetLength().

Et comme Delphi 7 connaît aussi les String...

Merci pour l'explication. Ça commence à rentrer.

J'ai pu faire les modifications qui restaient. Je n'ai eu qu'à suivre vos indications :

Code :

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

procedure InitGraph(var driver,mode:smallint; const title:{short}string);

Code :

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

{buf[0]:=Chr(nrchar);}SetLength(buf, nrchar);

J'ai même pu compiler mon programme d'échecs, mais il ne joue plus les mêmes coups !

Pourtant je n'ai pas utilisé de ShortString. Je vais suivre les avertissements du compilateur pour essayer de voir d'où cela vient.

[tourlourou]

J'ai même pu compiler mon programme d'échecs, mais il ne joue plus les mêmes coups !

Est-il du même niveau, pour autant ?

Comment est choisi le coup parmi ceux aussi bien notés ? Random ? Y a-t-il utilisation de la fonction randomize pour initialiser le générateur pseudo-aléatoire ?

Voici une discussion à propos des générateurs D5 et D7 : http://www.developpez.net/forums/d11...random-delphi/ où Paul Toth évoque qu'il n'y aurait pas de différence fondamentale dans XE2.

[Roland Chastain]

Est-il du même niveau, pour autant ?

Comment est choisi le coup parmi ceux aussi bien notés ? Random ? Y a-t-il utilisation de la fonction randomize pour initialiser le générateur pseudo-aléatoire ?

Pour le niveau je ne saurais pas dire. Je n'ai pas suffisamment testé le programme, qui n'est opérationnel que depuis hier.

Parmi les coups qui ont la même note, c'est le premier qui est joué. Je n'ai pas utilisé la fonction Random.

Merci pour le lien. Je vais creuser la question et dès que je trouve une réponse je reviens en parler.

[tourlourou]

Ceci voudrait dire qu'il ne trouve pas les coups dans le même ordre.

Ton D7 et ton XE2 sont-ils sur la même machine ? En win32 tous les 2 ?

[Roland Chastain]

Ceci voudrait dire qu'il ne trouve pas les coups dans le même ordre.

Peut-être.

Ton D7 et ton XE2 sont-ils sur la même machine ? En win32 tous les 2 ?

La même machine, le même Windows 7, vraiment rien de particulier. C'est peut-être tout simplement une erreur dans mon programme qui produit des résultats inattendus. Je vais reprendre l'ensemble à la loupe, en commençant par tous les endroits qui me valent un avertissement du compilateur. Il y en a quelques-uns.

[edam]

dans l'aide de delphi:

Sur la plate-forme Win32, vous pouvez utiliser la directive {$H-} pour transformer string en ShortString. C'est une technique potentiellement utile lors de l'utilisation d'anciens codes Turbo Pascal ou Delphi 16 bits avec vos programmes actuels.

[Roland Chastain]

Bon à savoir. Merci !

J'ai continué de tester l'unité WinGraph sous XE2. J'ai fait quelques modifications supplémentaires, et j'ai également modifié l'unité WinCrt. Je n'ai plus d'avertissements.

Toutefois, l'exemple ci-joint donne sous XE2 un résultat étrange. Les caractères de la chaîne ne sont pas bien rangés. D'où cela peut-il venir ?

[istam3]

Bonjour, comme j'ai suivi la discussion j'ai testé tes deux projets consoles, je n'ai eu aucun problème avec les chaînes saisies (à part que pas d'accent), tout m'a semblé Ok.

Pour le jeu d'échec, je suis fan et joueur de club (~1850 elo fide), alors si t'as besoin d'un testeur...ou d'évaluer le niveau, ton prog calcule-t-il tout ses coups et possibilités dés le début ou bien tu as intégré une bibliothèque d'ouverture ?

[Roland Chastain]

Bonjour, comme j'ai suivi la discussion j'ai testé tes deux projets consoles, je n'ai eu aucun problème avec les chaînes saisies (à part que pas d'accent), tout m'a semblé Ok.

C'est gentil d'avoir testé.

J'ai peut-être fait une confusion. Je vais revoir ça un peu plus tard. Rien ne presse : pour le moment je continue mon programme d'échecs avec Delphi 7 et les unités originales.

Pour le jeu d'échec, je suis fan et joueur de club (~1850 elo fide), alors si t'as besoin d'un testeur...ou d'évaluer le niveau, ton prog calcule-t-il tout ses coups et possibilités dés le début ou bien tu as intégré une bibliothèque d'ouverture ?

Très volontiers ! Ton avis sera le bienvenu. La dernière version du programme se trouve là. Je pense poster un code un peu meilleur dans la soirée. Je viens de corriger une erreur qui empêchait mes pions de prendre. C'est pour te dire que le programme a encore besoin d'être travaillé.

Pour la bibliothèque, il n'y en a pas pour le moment, mais j'en ai une que j'ai faite moi-même avec les Pro Deo utilities d'Ed Schröder. Je pense l'ajouter plus tard, quand j'aurai suffisamment testé mon moteur.

[Roland Chastain]

Bonjour !

J'ai refait à tête reposée le test que j'avais proposé plus haut.

Le test consiste à compiler le même code (console.dpr) d'une part avec Delphi 7 d'autre part avec XE2. Or avec XE2 le code s'exécute mais l'affichage n'est pas "normal" : le curseur est plus large, les caractères sont espacés d'une façon irrégulière. Ou est-ce chez moi seulement ?

N'hésitez pas à me faire part de vos idées. Il ne manque pas grand chose pour que les utilisateurs de XE2 puisse disposer d'une unité WinGraph 100% opérationnelle.

L'affaire dépasse mes compétences. Comme il n'y a plus de messages d'erreur, je ne sais plus trop de quel côté chercher.

[istam3]

Effectivement à la compil sous XE2

l'affichage n'est pas "normal" : le curseur est plus large, les caractères sont espacés d'une façon irrégulière. Ou est-ce chez moi seulement ?

en fait ce n'est plus la même police apparemment Courrier New sous D7, dont tout les caractères ont la même largeur d'où la régularité; sous XE2 la police n'est pas fixe mais les caractéres sont espacés de façon à être régulier d'où leur espacement non régulier,
ce n'est donc pas que chez toi, j'ai testé sous D7 pour voir l'affichage de base, puis sous D2009 et là on retrouve la même affichage qu'avec XE2 - je pressentais donc quelque chose venant du passage à l'unicode et concernant l'initialisation de la police utilisé dans le prog, voilà ce que j'ai trouvé, dans l'unit Wingrah ligne
2753 (procedure SetTextStyle(font,direction,charsize:word)

Code :

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

1
2
3
4
5
6
7
      {$IFDEF FPC}
      lfFaceName:=fontname;
      {$ELSE}
      //Move(fontname[1],lfFaceName[0],Length(fontname));//=> Ne peut fonctionner copie de caractéres codés sur un nombre d'octet différent
      for i := 0 to Length(fontname) - 1 do
        lfFaceName[i]:= WideChar(fontname[i+1]);
      {$ENDIF}

ma correction est primaire, mais elle fonctionne, la police est de nouveau initialisé correctement.

Si tu regardes l'unité Windows dans D7 et dans D2009, au niveau de la déclaration de tagLOGFONT, il y a deux déclarations différentes pour lfFaceName, celle utilisé lors de la compil non unicode (D7)

Code :

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

    lfFaceName: array[0..LF_FACESIZE - 1] of AnsiChar;

lors de la compil unicode (D2009, XE2)

Code :

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

    lfFaceName: array[0..LF_FACESIZE - 1] of WideChar;

à priori c'est le seul move() qui pose problème, pour les quelques autres les types sont correctes.

[Roland Chastain]

Génial !

Merci pour le code et pour les explications.