Table de correspondance types de données api/pascal objet

Soyez le premier à donner votre avis sur cette source.

Vue 11 882 fois - Téléchargée 1 207 fois

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.

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

japee
Messages postés
1711
Date d'inscription
vendredi 27 décembre 2002
Statut
Modérateur
Dernière intervention
19 novembre 2019
1 -
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...)
f0xi
Messages postés
4200
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
2 janvier 2019
26 -
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 :)
f0xi
Messages postés
4200
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
2 janvier 2019
26 -
@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.
cirec
Messages postés
3809
Date d'inscription
vendredi 23 juillet 2004
Statut
Modérateur
Dernière intervention
1 septembre 2019
33 -
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
cirec
Messages postés
3809
Date d'inscription
vendredi 23 juillet 2004
Statut
Modérateur
Dernière intervention
1 septembre 2019
33 -
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

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.