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

Messages postés
390
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
- - Dernière réponse : japee
Messages postés
1715
Date d'inscription
vendredi 27 décembre 2002
Statut
Modérateur
Dernière intervention
2 décembre 2019
- 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

japee
Messages postés
1715
Date d'inscription
vendredi 27 décembre 2002
Statut
Modérateur
Dernière intervention
2 décembre 2019
2 -
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
34 -
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
34 -
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
f0xi
Messages postés
4200
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
2 janvier 2019
26 -
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)
cs_MAURICIO
Messages postés
2233
Date d'inscription
mardi 10 décembre 2002
Statut
Modérateur
Dernière intervention
15 décembre 2014
5 -
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+
cs_Jean_Jean
Messages postés
637
Date d'inscription
dimanche 13 août 2006
Statut
Membre
Dernière intervention
13 décembre 2018
2 -
@ 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
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.
cs_Delphiprog
Messages postés
4580
Date d'inscription
samedi 19 janvier 2002
Statut
Modérateur
Dernière intervention
9 janvier 2013
24 -
@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.
flo160fr
Messages postés
162
Date d'inscription
dimanche 19 novembre 2000
Statut
Membre
Dernière intervention
14 avril 2009
-
bien pratique ce pdf ^^
cs_neko
Messages postés
135
Date d'inscription
jeudi 14 août 2003
Statut
Membre
Dernière intervention
12 octobre 2006
-
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é.
cs_Jean_Jean
Messages postés
637
Date d'inscription
dimanche 13 août 2006
Statut
Membre
Dernière intervention
13 décembre 2018
2 -
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
cs_Delphiprog
Messages postés
4580
Date d'inscription
samedi 19 janvier 2002
Statut
Modérateur
Dernière intervention
9 janvier 2013
24 -
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 ?
John Dogget
Messages postés
390
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
-
> 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 ...
Francky23012301
Messages postés
400
Date d'inscription
samedi 6 août 2005
Statut
Membre
Dernière intervention
11 février 2016
1 -
Hé hé hé : bien pratique ce petit PDF.

Encore un truc bien utile : Merci Monsieur.
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.
John Dogget
Messages postés
390
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
-
C'est une bonne idée, parfois c'est galère pour utiliser les APIs ...