TABLE DE CORRESPONDANCE TYPES DE DONNÉES API/PASCAL OBJET api, types, reference, card, pascal, Source N°39668

Information sur la source

Catégorie :Trucs & Astuces Classé sous : api, types, reference, card, pascal Niveau : Initié Date de création : 23/09/2006 Date de mise à jour : 24/09/2006 08:39:22 Vu / téléchargé: 4 891 / 761

Auteur : Delphiprog

Site perso

Ecrire un message privé

Note :

9,75 / 10

1
2
3
4
5
6
7
8
9
10

Commentaire sur cette source (18)

Ajouter un commentaire et/ou une note

Description

Ce n'est pas un code source que je vous propose mais une table de correspondance entre les types de données de Windows et leur équivalent en Pascal Objet.
Pour ceux qui ont des difficultés à traduire les types de données déclarés dans MSDN ou autre SDK, voilà un document qui vous rendra sûrement service.
Il vous suffit de l'imprimer et de le garder à portée de main (ou plutôt de clavier).
Il a été concu sur le principe des "Quick Reference Card" bien connus : le maximum d'informations utiles dans un minimum d'espace.

Fichier Zip

Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Windows Data Types-Object Pascal.pdf8 959 octets

Télécharger le zip

Historique

24 septembre 2006 08:39:22 :: Corrections suite aux remarques pertinentes de Florenth sur les types 32 bits non signés(UINT et ULONG). Merci à lui.

Sources du même auteur

Toutes les sources de Delphiprog

Sources de la même categorie

Toutes les sources de la catégorie Trucs & Astuces

Sources en rapport avec celle ci

Commentaires

Commentaire de John Dogget le 23/09/2006 17:43:39

C'est une bonne idée, parfois c'est galère pour utiliser les APIs ...
Commentaire de florenth le 23/09/2006 21:35:51

Bonne idée de faire ces cartes.
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.
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 John Dogget le 23/09/2006 22:39:38

> Florenth
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 ...
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 Jean_Jean le 24/09/2006 15:01:56

C'est Bien utile!
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
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 flo160fr le 25/09/2006 18:07:03

bien pratique ce pdf ^^
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 florenth le 26/09/2006 17:22:58

Oui oui, le dwSize, je n'y pensais pas ... Maintenant, je comprend mieux le pourquoi du comment.
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.
Commentaire de Jean_Jean le 26/09/2006 18:01:21

@ Delphiprog
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
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 f0xi le 27/09/2006 19:32:29 administrateur CS

excelent, ça me fait penser a l'outil dispo sur jedi ...

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)
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 cirec le 29/09/2006 14:37:42 administrateur CS

Autre chose :
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
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.
Commentaire de f0xi le 09/10/2006 18:17:35 administrateur CS

aussi, tu le dis trés bien :

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 :)
Commentaire de japee le 16/10/2006 00:26:18 administrateur CS

Very useful, this Quick Reference Card...

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...)

Ajouter un commentaire

Discussions en rapport avec ce code source

Smart Card Reader et API par Jeankiki

problèmes de bibliothèques par costello

les api windows par alami467

T.Pascal par pheubus

Pascal / ASM - Erreur.... :-( par smena

programmation jeu de dames sur delphi4.0 en pascal par Laurie

Lecture API par Manu93

Livre Delphi ou Pascal ? par stailer

Isoler un caractère d'une chaîne... par mentral

api par cafnoire