TABLE DE CORRESPONDANCE TYPES DE DONNÉES API/PASCAL OBJET
John Dogget
Messages postés
384
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
-
23 sept. 2006 à 17:43
japee Messages postés 1727 Date d'inscription vendredi 27 décembre 2002 Statut Modérateur Dernière intervention 6 novembre 2021 - 16 oct. 2006 à 00:26
japee Messages postés 1727 Date d'inscription vendredi 27 décembre 2002 Statut Modérateur Dernière intervention 6 novembre 2021 - 16 oct. 2006 à 00:26
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/39668-table-de-correspondance-types-de-donnees-api-pascal-objet
https://codes-sources.commentcamarche.net/source/39668-table-de-correspondance-types-de-donnees-api-pascal-objet
16 oct. 2006 à 00:26
J'y ai découvert deux ou trois bricoles intéressantes.
Ce qui est appréciable dans ce genre de document, c'est d'avoir tout sous la main très vite.
Donc, au total gain de temps, et utilité certaine.
Je vais l'afficher dans mon environnement de programmation.
(quand j'aurai réussi à remettre en marche cette p#@%! d'imprimante...)
9 oct. 2006 à 18:17
LPCTSTR = PAnsiChar; { utilisez PWideChar si systeme UNICODE (UTF-16) }
LPTSTR = PAnsiChar; { idem }
il est vrai que ce serait plus parlant si au lieu de Ansi et Wide on identifie les types de cette façon : P8bitChar et P16bitChar :)
9 oct. 2006 à 18:10
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.
29 sept. 2006 à 14:37
dans Windows.pas il est déclaré :
LPCTSTR = PAnsiChar; { should be PWideChar if UNICODE }
LPTSTR = PAnsiChar; { should be PWideChar if UNICODE }
pour vous en rendre compte voir snippet ici :
http://www.codyx.org/snippet_extraire-afficher-icone-fichier-dll-exe_97.aspx
Function PickIconDlgW(OwnerWnd: HWND; lpstrFile: PWideChar; var nMaxFile: LongInt; var lpdwIconIndex: LongInt): LongBool; stdcall; external
'SHELL32.DLL' index 62;
Essayez de remplacer : lpstrFile: PWideChar par lpstrFile: PAnsiChar (bien sur il faudra adapter la suite du code en conséquence)
Je vous laisse le soin de découvrir les problèmes (rien de grave je vous rassure :-))
Bonne chance :-)
@+
Cirec
29 sept. 2006 à 12:58
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
27 sept. 2006 à 19:32
par contre, un petit truc si je ne m'abuse, DWORD est l'alias de LongWord
est donc par le fait, la meilleur traduction serait :
DWORD = LongWord
PDWORD = PLongWord / ^LongWord
LPDWORD = PLongWord / ^LongWord
mais bon, ces chipoter pour rien ... dword, longword, cardinal c'est kifkif.
mais en tout cas, en pdf c'est toujours utile, ce serait peut etre encore mieux en HLP pour l'incruster directement dans l'aide delphi :) (a penser)
27 sept. 2006 à 10:54
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+
26 sept. 2006 à 18:01
Je confirme qu'avec Delphi 7, version réduite, on a accès au code source,ce qui répond à de nombreuses questions que je me posai. ça me fait une bonne révision!
Mais je confirme aussi que toute synthèsesimplificatrice est toujours bonnepour certainstypes de programmeurs. commeça fait qlq années que je n'ai pas codé, ça me remet en piste, même si je suis un pinailleur également comme tout bon programmeur. donc , Merci encore DelphiProg!
@ Neko et Florenth : Merci à vous aussi pour vos remarques pertinentes! Passionnant.
Delphi votre
Jean_Jean
26 sept. 2006 à 17:22
Sinon, les éditions Perso ont accès (en tout cas la 6~7) au code des unités Windows, Classes, Messages, MMSystem et deux trois autres qui n'ont que des constantes.
Dans TurboDelphi, on a accès à tout le code source de toutes les unités de tout ^^. Même les unités de DB et celles du DecisionCube.
25 sept. 2006 à 21:32
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.
25 sept. 2006 à 18:07
25 sept. 2006 à 10:56
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é.
24 sept. 2006 à 15:01
il faudrait presque une dénomination à part pour ce type de document de synthèse pratique.
ça pourrait figurer dans Doc.
Quand je pense que j'ai donné un vieux bouquin sur les 1000 fonctions API. C'était un bon livre, très pédagogique...! Je crois bien qu'il n'y a plus l'équivalent aujourd'hui.
Bien @ toi
Jean_Jean
24 sept. 2006 à 08:44
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 ?
23 sept. 2006 à 22:39
Sans compter que comme tu le dis les types sont tous sur 32 bits, alors que rares sont les operations qui réellement besoin de ces 32 bits : parfois un simple boolean suffit ...
23 sept. 2006 à 22:26
Encore un truc bien utile : Merci Monsieur.
23 sept. 2006 à 21:35
C'est ce que j'aurais bien aimé il y a quelques années ...
Juste une remarque cependant :
ULONG UINT DWORD = HBRUSH = HBITMAP = HICON = Hxxx = COLORREF = THandle = LongWord = Cardinal
et
LongInt = Integer
En bref, il faut juste faire la distinction entre signé et non signé. Et encore ce n'est pas forcément la peine puisque on s'en sert juste pour les appels aux APIs, ces types faisant tous 32 bits.
Par la même occasion, il n'est pas inutile de rappeler que Windows.pas définit l'équivalence de tous ces types vers les types conventionnels du pascal.
Tiens, par contre, dans Windows.pas, j'ai ULONG = Cardinal et non pas Integer comme tu le dis dans ton pdf. Etrange, serait-ce une erreur d'inatention, de version, ou bien un acte bien pesé ?
"Object Pascal does not have a true unsigned integer data type"
Ah bon ? Byte, Word et Cardinal sont biens non-signés, non ?
--------------------
Ce qui est vraiment galère dnas les APIs, John, ce sont les types-méthodes. Non seulement, il ne faut pas se tromper ni dans l'ordre, ni dans le type des paramètres, mais en plus, il faut mettre la bonne convention d'appel et tout Pfff, moi, y'a toujours un de ces détails qui m'échappe et là, c'est le plantage assuré. Sans compter les paramètres tableaux ou les record qui sont parfois "packed" sans que cela soit mentionné ...
Là, c'est bon, ya de quoi se prendre la tête pour un sacré moment. ^^ Rien que d'y penser, ça me donne déjà des céphalées.
23 sept. 2006 à 17:43