TABLE DE CORRESPONDANCE TYPES DE DONNÉES API/PASCAL OBJET

Commentaire de Francky23012301 le 23/09/2006 22:26:05

Hé hé hé : bien pratique ce petit PDF.

Encore un truc bien utile : Merci Monsieur.

Commentaire de Delphiprog le 24/09/2006 08:44:41 administrateur CS

Merci pour vos remarques et/ou encouragements.
Je m'attendais à une volée de bois vert pour l'avoir écrit en anglais mais il n'en est rien. Je suis soulagé de ce côté là et tant mieux car je n'ai jamais réussi à trouver de "reference card" semblable sur le net.

@Florenth : "les record qui sont parfois "packed" sans que cela soit mentionné"
C'est bien pour cela qu'il y a toujours un membre nommé dwSize pour renseigner sur la taille de la structure transmise, non ?

Commentaire de neko le 25/09/2006 10:56:28

comme le dit florenth, tous ces types sont déjà déclarés dans l'unité windows donc je vois pas bien l'utilité. Il est bien plus lisible d'utiliser un HBRUSH plutôt qu'un LongWord ( par exemple qui correspond plus à l'API )
de plus certains de ces types sont déclarés incompatibles entre eux ( type_api= type type_correspondant )  donc désolé, mais là je vois vraiment pas l'utilité.

Commentaire de Delphiprog le 25/09/2006 21:32:02 administrateur CS

@Neko : selon le niveau du développeur, on peut ressentir des besoins différents.
Je suis d'accord avec toi, les différents types sont déclarés dans l'unité Windows.pas. Cependant, je n'ai pas pu vérifier si les utilisateurs d'une édition personnelle de Delphi avaient accès au code source de cette unité.
En ce qui concerne la lisibilité d'un HBRUSH par rapport à un longword, d'une part c'est subjectif et d'autre part, rien n'oblige à remplacer un HBRUSH par un longWord dans un appel à une API.
Il y a donc plusieurs publics pour ce genre de document. Cela va du débutant qui veut mieux comprendre à quoi cela correspond tel ou tel type au développeur confirmé qui connait, à force de les utiliser, chacune de ces déclarations.
De la même façon, on peut trouver des références cards sur les combinaisons de touches à utiliser, que ce soit pour Delphi ou tout autre logiciel. On peut aussi dire que cela ne sert à rien quand on manipule ce logiciel depuis un certain temps. En revanche, le débutant trouvera cela très utile.

Si tu trouves ce document inutile, alors je suis heureux pour toi. C'est la preuve que tu maîtrises parfaitement le sujet !

Mais, avec le temps, on a parfois des trous de mémoire et là, on est aussi bien content d'avoir ce genre de documents pour se rafraîchir la mémoire.

@flo160fr : merci.

Commentaire de MAURICIO le 27/09/2006 10:54:16

Salut DelphiProg,
c' est une bonne initiative de ta part.
Haaa si j' avais eu ce document il y a quelques années auparavant :)  ...

Je l' ai imprimé, ça va servir un de ces 4, je vais même peut etre le faire encadrer (lol) ...
A+

Commentaire de cirec le 29/09/2006 12:58:02 administrateur CS

Salut,

moi il y a une chose qui me dérange :

compte tenu de ce que dit l'aide de Delphi
Integer –2147483648..2147483647 32 bits signé
Longword 0..4294967295 32 bits non signé
des déclarations dans Windows.pas

THandle devrait être de type LongWord où Cardinal mais en aucun cas de type Integer avec tout ce que cela implique pour la partie droite du pdf

Ainsi que HWND et HHOOK

Pour ceux qui ne le savent pas :
Dans l'EDI rester appuyé sur Ctrl et avec le mulot cliquer sur la variable de votre choix et là, oh miracle, Delphi vous transporte directement dans la partie du code ou la variable a été déclarée.

Faites un essaie avec THandle
@+
Cirec

Commentaire de f0xi le 09/10/2006 18:10:39 administrateur CS

@cirec : tu as parfaitement raison pour les handle ... j'avais deja soulevé le probleme en disant qu'un handle devrait toujours etre un entiers non signé 32 bits.

mais bon, il faut savoir que integer/cardinal/longword stock les données de la meme façon, c'est juste que pour obtenir les nombres negatif on considere que tout les nombre superieur a $80000000 sont negatif pour Integer.

cardinal/longword :
> $00000000 .. $FFFFFFFF // 0..44294967295

integer :
> $00000000 .. $7FFFFFFF // 0..2147483647
> $80000000 .. $FFFFFFFF // -2147483648..-1

et donc la valeur $80000000 en 32bits non signés vaut 2147483648 ect...
quand on transtype l'integer vers cardinal et cardinal vers integer on obtient donc toujours une valeur correspondante exacte et de par le fait on ne doit pas avoir d'erreur.

mais il faut adapter en fonction de la declaration du handle si il est en INT (integer) ou en DWORD (cardinal/longword).
mais il est rare dans l'api windows de voir un handle declaré en INT.
bien entendus, la valeur de INVALID_HANDLE_VALUE (0) est toujours bonne que ce soit en cardinal ou en integer puisque dans les deux cas 0 = $00000000.

c'est comme les adresses de pointeur, qu'elle soit en integer ou cardinal, vus qu'elle sont stockée dans un registre 32bit non signé (le signe est stocké dans un autre registre) il n'y a pas non plus d'erreur quand on appel par exemple un handle ou pointeur qui contient par exemple $85002512, vus que le cpu prendras automatiquement une valeur absolue en ignorant le registre du signe.
mais bon, il vaut mieux eviter de jongler dangereusement avec les signes car ça peu parfois provoquer des bugs innatendus, meme si ça reste rare.
avec les entiers surtout il n'y a pas trop de probleme, la ou il faut faire attention c'est avec les flottant qui sont stockés d'une façon totalement differente et donc les données hexa contiennent des informations sur le nombre de decimales, le signes ect... c'est d'ailleur pour cela que les shr, shl, ror, rol ect... ne fonctionne pas directement sur les flottant et que les fonction asm sont prevus pour les deux types (entier/flottant) :
entier : add, sub, mul, div
flottant : fadd, fsub, fmul, fdiv (f pour float)

pour ce qui est de PWideChar et PAnsiChar la aussi, c'est une question de faire attention a ce qui est declaré dans l'API windows, parfois c'est l'un et parfois c'est l'autre ...

WideChar --> compatible UTF-16 et autres codages sur 16bits
AnsiChar --> compatible UTF-8 et autres codages sur 8bits

c'est donc normal que de l'un a l'autre le transtypage est assé difficile a réaliser et que si on ce trompe de type, le resutlat serat erroné.
surtout que comme AnsiChar est une chaine a zero terminal, elle s'arreterat au premier caractere d'une chaine WideChar et en inversement (Ansi vers Wide) on ne pourrat pas decoder les caracteres 16 bits qui seront inexistant ou faux dans la table UTF-16 et donc on risque de se retrouver avec des caracteres japonais, arabes, russe ou je ne sais trop quoi d'autres ... bref une suite de petit carré a la place d'une chaine lisible. ;)

de toute façon, c'est une erreur qui serat facilement detectable si on sais cela.