(API) Utilisation de DocumentProperties()

**Baptiste.C** · 22/04/2010, 17h43

Bonjour à tous,

Je suis actuellement en train d'explorer le monde merveilleux des API liées à l'impression (d'étiquettes avec imprimante à ruban Zebra ZM600 200dpi (ZPL)). Je voudrai d'ailleurs pouvoir informer l'imprimante d'un changement de format d'étiquette sans que l'utilisateur n'aie à fouiller dans les options d'impression.
De fil en aiguille j'ai mis la main sur l'API "DocumentPropertiesA" qui permet de récupérer des informations sur le driver d'une imprimante ou de le modifier à loisir.
Mais voilà, je bute sur l'utilisation de la coquine. Voici sans plus attendre le code que j'utilise :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
PROCEDURE PR_TEST_GetDocumentProperties(sUnNomDImprimante est une chaîne)
 
nWindowHandle 		est un entier
nPrinterHandle 		est un entier
sPrinterName 		est une chaîne = sUnNomDImprimante
nDEV_MODE_OUT		est un entier
nTailleBuffer 		est un entier
nRetourFonction		est un entier
DevMode 			est un STDEVMODE
 
// Récupération du handle de l'imprimante
nRetourFonction = API("winspool.drv", "OpenPrinterA",&sPrinterName,&nPrinterHandle,Null)
 
// Premier appel "à vide" pour récupérer la taille du buffer à créer
nTailleBuffer = API("WINSPOOL.DRV", "DocumentPropertiesA", Handle(), nPrinterHandle, &sPrinterName, Null, Null, Null)
 
// Création du buffer
nDEV_MODE_OUT = API("KERNEL32", "GlobalAlloc", 0x0040, nTailleBuffer)
 
// 2° appel pour récupération des informations concernant le driver dans nDEV_MODE_OUT
nRetourFonction = API("WINSPOOL.DRV", "DocumentPropertiesA", Handle(), nPrinterHandle, &sPrinterName, nDEV_MODE_OUT, Null, "DM_OUT_BUFFER")
 
// Transfert des informations dans une structure DEVMODE
API("kernel32","RtlMoveMemory",&DevMode,&nDEV_MODE_OUT,Taille(nDEV_MODE_OUT))
 
// Fermeture de l'imprimante
API("WINSPOOL.DRV","ClosePrinter",nPrinterHandle)
 
ch est une chaîne = "Name : "+DevMode:dmDeviceName
ch+=RC+"Version : "+DevMode:dmSpecVersion
ch+=RC+"Driver version : "+DevMode:dmDriverVersion
ch+=RC+"Size : "+DevMode:dmSize
ch+=RC+"Driver Extra : "+DevMode:dmDriverExtra
ch+=RC+"Fields : "+DevMode:dmFields
ch+=RC+"Orientation : "+DevMode:dmOrientation
ch+=RC+"PaperSize : "+DevMode:dmPaperSize
ch+=RC+"PaperLength : "+DevMode:dmPaperLength
ch+=RC+"Paperwidth : "+DevMode:dmPaperWidth
ch+=RC+"Scale : "+DevMode:dmScale
ch+=RC+"Copies : "+DevMode:dmCopies
ch+=RC+"Qualité : "+DevMode:dmPrintQuality
ch+=RC+"FormName : "+DevMode:dmFormName
Info(ch)
 
nRetourFonction = API("KERNEL32","GetLastError")
ErrorMessage est une chaîne = GetErrorMessage(nRetourFonction)

La fenêtre des options d'impression s'affiche comme convenu, mais ma structure DevMode reste désespérément vide et pour cause : GetLastError me renvoie le code erreur n°13, qui correspond à "The data is invalid". Je n'ai pas réussi à avoir mieux que cela.

Si quelqu'un pouvait m'éclairer sur l'utilisation de cette API j'en serai fort obligé !

Annexe :
Doc MSDN sur l'API : http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
Exemple d'utilisation (pas en W-Langage) : http://www.amyuni.com/downloads/tn02.htm

(Edit) - Oh ! Et j'utilise WD14 et XP SP3, si peut faire avancer l'affaire ...

**=JBO=** · 22/04/2010, 19h54

Bonjour,

Dans le "monde merveilleux" des API, chaque détail compte.
Entre autres:
_ • la définition des structures de données,
_ • les types de données des paramètres passés aux API.

Par exemple, en ce qui te concerne, il aurait fallu nous donner la structure DEVMODE pour que nous puissions vérifier que sa définition est correcte.

Concernant l'API DocumentPropertiesA, tu n'as pas bien compris l'usage du paramètre fMode qui doit recevoir une valeur de type DWORD (traduction en WLangage: entier sur 4 octets) et non pas une chaîne de caractères.

Quelques remarques sur le WLangage et les API:

Si tu as besoin d'allouer une zone mémoire pour "discuter" avec l'API tu peux utiliser le type Buffer du WLangage.
Pour copier un bloc de mémoire, tu peux utiliser la fonction Transfert().
La fonction ErreurInfo() sait récupérer le n° de la dernière erreur système ainsi que le message correspondant à cette erreur.

_

**Baptiste.C** · 22/04/2010, 20h56

Merci pour cette réponse rapide !

il aurait fallu nous donner la structure DEVMODE pour que nous puissions vérifier que sa définition est correcte.

Tout à fait, j'ai oublié de l'attacher à mon précédent message, autant pour moi ... La voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 
STDEVMODE est une structure
	dmDeviceName est une chaîne fixe sur 32 //Type C : BYTE
	dmSpecVersion est un entier sur 2 octets //Type C : WORD
	dmDriverVersion est un entier sur 2 octets //Type C : WORD
	dmSize est un entier sur 2 octets //Type C : WORD
	dmDriverExtra est un entier sur 2 octets //Type C : WORD
	dmFields est un entier sur 4 octets sans signe //Type C : DWORD
	dmOrientation est un entier sur 2 octets //Type C : short
	dmPaperSize est un entier sur 2 octets //Type C : short
	dmPaperLength est un entier sur 2 octets //Type C : short
	dmPaperWidth est un entier sur 2 octets //Type C : short
	dmScale est un entier sur 2 octets //Type C : short
	dmCopies est un entier sur 2 octets //Type C : short
	dmDefaultSource est un entier sur 2 octets //Type C : short
	dmPrintQuality est un entier sur 2 octets //Type C : short
	dmColor est un entier sur 2 octets //Type C : short
	dmDuplex est un entier sur 2 octets //Type C : short
	dmYResolution est un entier sur 2 octets //Type C : short
	dmTTOption est un entier sur 2 octets //Type C : short
	dmCollate est un entier sur 2 octets //Type C : short
	dmFormName est une chaîne fixe sur 32 //Type C : BYTE
	dmLogPixels est un entier sur 2 octets //Type C : WORD
	dmBitsPerPel est un entier sur 4 octets sans signe //Type C : DWORD
	dmPelsWidth est un entier sur 4 octets sans signe //Type C : DWORD
	dmPelsHeight est un entier sur 4 octets sans signe //Type C : DWORD
	dmDisplayFlags est un entier sur 4 octets sans signe //Type C : DWORD
	dmDisplayFrequency est un entier sur 4 octets sans signe //Type C : DWORD
	dmICMMethod est un entier sur 4 octets sans signe //Type C : DWORD
	dmICMIntent est un entier sur 4 octets sans signe //Type C : DWORD
	dmMediaType est un entier sur 4 octets sans signe //Type C : DWORD
	dmDitherType est un entier sur 4 octets sans signe //Type C : DWORD
	dmICCManufacturer est un entier sur 4 octets sans signe //Type C : DWORD
	dmICCModel est un entier sur 4 octets sans signe //Type C : DWORD
	dmPanningWidth est un entier sur 4 octets sans signe //Type C : DWORD
	dmPanningHeight est un entier sur 4 octets sans signe //Type C : DWORD
FIN

fMode [...] doit recevoir une valeur de type DWORD (traduction en WLangage: entier sur 4 octets) et non pas une chaîne de caractères.

Effectivement je n'ai pas bien assimilé cette affaire ; fMode doit recevoir une constante ?

**=JBO=** · 22/04/2010, 21h12

Merci pour tes précisions.

Je constate que, pour définir la structure DEVMODE, tu as utilisé l'outil WDAPI fourni avec WinDev.
C'est une bonne idée.
Hélas, il faut se méfier des conversions proposées par WDAPI car elles ne sont pas toujours correctes.

Voilà ce que je te recommande de déclarer dans le traitement de déclaration d'une collection de procédures (par exemple).

[EDIT]
J'utilise WinDev 12 et dans cette version WDAPI ne donne pas toujours de bons résultats.
En revanche, la définition de la structure DEVMODE que tu nous as donné est correcte.
Quelle est ta version de WinDev ?
[/EDIT]

Au passage, tu verras que j'ai défini 5 constantes (elles aussi données par WDAPI

) utiles pour définir la structure DEVMODE ou pour appeler l'API.

Code WLangage :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
CONSTANTE
	CCHDEVICENAME=32
	CCHFORMNAME=32
 
	DM_IN_BUFFER=8  //DM_MODIFY
	DM_IN_PROMPT=4  //DM_PROMPT
	DM_OUT_BUFFER=2  //DM_COPY
FIN
 
STDEVMODE est une structure
	dmDeviceName est un Buffer sur CCHDEVICENAME
	dmSpecVersion est un entier sur 2 octets sans signe 
	dmDriverVersion est un entier sur 2 octets sans signe
	dmSize est un entier sur 2 octets sans signe
	dmDriverExtra est un entier sur 2 octets sans signe
	dmFields est un entier sur 4 octets sans signe
	dmOrientation est un entier sur 2 octets
	dmPaperSize est un entier sur 2 octets
	dmPaperLength est un entier sur 2 octets
	dmPaperWidth est un entier sur 2 octets
	dmScale est un entier sur 2 octets
	dmCopies est un entier sur 2 octets
	dmDefaultSource est un entier sur 2 octets
	dmPrintQuality est un entier sur 2 octets
	dmColor est un entier sur 2 octets
	dmDuplex est un entier sur 2 octets
	dmYResolution est un entier sur 2 octets
	dmTTOption est un entier sur 2 octets
	dmCollate est un entier sur 2 octets
	dmFormName est un Buffer sur CCHFORMNAME
	dmLogPixels est un entier sur 2 octets sans signe
	dmBitsPerPel est un entier sur 4 octets sans signe
	dmPelsWidth est un entier sur 4 octets sans signe
	dmPelsHeight est un entier sur 4 octets sans signe
	dmDisplayFlags est un entier sur 4 octets sans signe
	dmDisplayFrequency est un entier sur 4 octets sans signe
	dmICMMethod est un entier sur 4 octets sans signe
	dmICMIntent est un entier sur 4 octets sans signe
	dmMediaType est un entier sur 4 octets sans signe
	dmDitherType est un entier sur 4 octets sans signe
	dmICCManufacturer est un entier sur 4 octets sans signe
	dmICCModel est un entier sur 4 octets sans signe
	dmPanningWidth est un entier sur 4 octets sans signe
	dmPanningHeight est un entier sur 4 octets sans signe
FIN

Envoyé par Baptiste.C

Effectivement je n'ai pas bien assimilé cette affaire ; fMode doit recevoir une constante ?

Pour le paramètre fMode tu peux soit donner la valeur symbolique Null (soit la valeur numérique 0), comme c'est le cas au premier appel, soit donner une des valeurs des constantes.
Dans ton cas, au 2ème appel il faut utiliser la valeur constante DM_OUT_BUFFER (c'est à dire la valeur 2).
_

**Baptiste.C** · 22/04/2010, 21h37

On avance !

J'obtiens maintenant l'erreur 122 : "the data area passed to a system call is too small", le buffer est donc de taille trop petite. Curieux puisque je récupère sa taille comme décrit dans la doc MSDN, à savoir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
// Premier appel "à vide" pour récupérer la taille du buffer à créer
nTailleBuffer = API("WINSPOOL.DRV", "DocumentPropertiesA", Handle(), nPrinterHandle, &sPrinterName, Null, Null, Null)
 
// Création du buffer
nDEV_MODE_OUT = API("KERNEL32", "GlobalAlloc", 0x0040, nTailleBuffer)

Y-t-il un autre moyen de connaitre la taille du buffer à créer ? (Les paramètres passés au dessus semblent être les bons pourtant)

Merci encore pour le coup de main JBO

**=JBO=** · 22/04/2010, 21h45

Je te propose une adaptation du code que tu as donné au départ.

Code WLangage :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
 
PROCEDURE PR_TEST_GetDocumentProperties(sUnNomDImprimante est une chaîne)
 
nWindowHandle est un entier
nPrinterHandle est un entier
sPrinterName est une chaîne = sUnNomDImprimante
nRetourFonction	est un entier
DevMode est un STDEVMODE
 
nTailleBuffer est un entier
bBuffer est un Buffer	// pour l'instant le Buffer est vide
 
// Récupération du handle de l'imprimante
nRetourFonction = API("winspool.drv", "OpenPrinterA",&sPrinterName,&nPrinterHandle,Null)
 
// Premier appel "à vide" pour récupérer la taille du buffer à créer
nTailleBuffer = API("WINSPOOL.DRV", "DocumentPropertiesA", Handle(), nPrinterHandle, &sPrinterName, Null, Null, Null)
 
// Allouer une zone mémoire pour le buffer
bBuffer = Répète(Caract(0), nTailleBuffer)
 
// 2° appel pour récupération des informations concernant le driver dans bBuffer
nRetourFonction = API("WINSPOOL.DRV", "DocumentPropertiesA", Handle(), nPrinterHandle, &sPrinterName, &bBuffer, Null, DM_OUT_BUFFER)
 
// Copie des données bBuffer dans la structure DEVMODE.
// Attention ! bBuffer peut contenir des informations supplémentaires, selon le driver.
Transfert(&DevMode, &bBuffer, Dimension(DevMode))
 
// Fermeture de l'imprimante
API("WINSPOOL.DRV","ClosePrinter",nPrinterHandle)
 
ch est une chaîne = "Name : " + Remplace(DevMode:dmDeviceName,Caract(0),"")
ch+=RC+"Version : "+DevMode:dmSpecVersion
ch+=RC+"Driver version : "+DevMode:dmDriverVersion
ch+=RC+"Size : "+DevMode:dmSize
ch+=RC+"Driver Extra : "+DevMode:dmDriverExtra
ch+=RC+"Fields : "+DevMode:dmFields
ch+=RC+"Orientation : "+DevMode:dmOrientation
ch+=RC+"PaperSize : "+DevMode:dmPaperSize
ch+=RC+"PaperLength : "+DevMode:dmPaperLength
ch+=RC+"Paperwidth : "+DevMode:dmPaperWidth
ch+=RC+"Scale : "+DevMode:dmScale
ch+=RC+"Copies : "+DevMode:dmCopies
ch+=RC+"Qualité : "+DevMode:dmPrintQuality
ch+=RC+"FormName : "+ Remplace(DevMode:dmFormName,Caract(0),"")
Info(ch)
 
nRetourFonction = ErreurInfo(errCodeSystème)
sErrorMessage est une chaîne  = ErreurInfo(errMessageSystème)
//nRetourFonction = API("KERNEL32","GetLastError")
//ErrorMessage est une chaîne = GetErrorMessage(nRetourFonction)

P.S. Pour la structure DEVMODE, je n'ai pas bien converti le type DWORD qui devient en WLangage entier sur 4 octets sans signe.
_

**Baptiste.C** · 22/04/2010, 22h02

C'est beau !

Mais, question peut-être bête, quelle est la différence fondamentale d'avec mon code ? Pour moi, tu crées un buffer de même taille, non ?

En tout cas ton aide est particulièrement appréciée. Si, au passage, tu connais des ressources (sites ou bouquins) intéressantes et plus explicites que WDAPI je suis preneur !

**=JBO=** · 22/04/2010, 22h14

Envoyé par Baptiste.C

Mais, question peut-être bête, quelle est la différence fondamentale d'avec mon code ? Pour moi, tu crées un buffer de même taille, non ?

Je ne cherche pas à faire des effets de style.
Il n'y a pas de différence fondamentale... J'essaye juste de te répondre en me plaçant dans la "philosophie" de notre outil de développement.
Ce n'est pas juste une conversion à l'identique d'un code C, c'est une adaptation.

Par exemple, l'utilisation d'un Buffer WLangage est quand même plus simple et plus "sécuritaire" que l'allocation directe d'une zone mémoire par le système d'exploitation.
En utilisant un Buffer WLangage, on se protège du risque d'une "fuite de mémoire" (qui survient fréquemment, quand on alloue une zone mémoire et qu'on oublie ensuite de la libérer explicitement).

Envoyé par Baptiste.C

Si, au passage, tu connais des ressources (sites ou bouquins) intéressantes et plus explicites que WDAPI je suis preneur !

Je n'ai pas grand chose à te proposer.

Quant à WDAPI, il semblerait que ta version de l'outil soit améliorée par rapport à celle que j'utilise, ce qui redonne de l'intérêt à cet outil.
(la structure DEVMODE que tu nous as donné est correctement traduite, ce qui n'est pas le cas dans ma "vieille" version).

J'en suis encore à WD12... et toi quelle version utilises-tu ?
Ah si ! Je viens de voir la fin de ton 1er message: tu utilises WD14.

Donc WDAPI_14 meilleur que WDAPI_12 !

_

**Baptiste.C** · 22/04/2010, 22h21

Je me souviendrai de tes précieux conseils, JBO !

**=JBO=** · 22/04/2010, 22h32

Bon courage pour la programmation de l'imprimante via les API...
Ce n'est pas toujours très simple... N'est-ce pas ?!

_

**Baptiste.C** · 22/04/2010, 22h38

Ah ça ! C'est pourquoi j'ai utilisé la formule "monde merveilleux des API liées à l'impression", à laquelle tu as judicieusement rajouté des guillemets, l'ironie est plus évidente de cette manière.
J'imagine qu'à force d'abnégation on arrive à tout, ou quelque chose d'approchant

**=JBO=** · 22/04/2010, 22h58

Envoyé par Baptiste.C

Mais, question peut-être bête, quelle est la différence fondamentale d'avec mon code ? Pour moi, tu crées un buffer de même taille, non ?

En y réfléchissant un peu plus, je vois une raison "fondamentale" pour préférer l'utilisation d'un Buffer WLangage plutôt qu'un appel à GlobalAlloc.

En effet, dans un Buffer WLangage, les données sont sous ton contrôle direct, et il est plus facile d'y "farfouiller" ou d'en extraire des portions de données.
Notamment, on peut utiliser l'opérateur [[ ]] pour extraire une portion de données, ou écrire "par-dessus" les données du Buffer.

Cela peut avoir son importance dans ta situation où les données retournées par l'API sont souvent d'une taille supérieure à celle de la structure qui y donne accès.
Tu auras sans doute besoin de lire ces données supplémentaires.. et un Buffer WLangage pourra te faciliter la tâche.
_

**Baptiste.C** · 22/04/2010, 23h08

Très intéressant, surtout que dès demain, je vais essayer d'y mettre mes propres valeurs pour les envoyer à l'imprimante.
Il faut absolument que je regarde précisément ce que je peux faire avec des variables déclarées buffer, j'avoue que je suis allé au casse-pipe sans regarder la doc WD en me concentrant presque uniquement sur les API et la transcription de code C ou VB vers W langage.

**=JBO=** · 23/04/2010, 00h07

Envoyé par Baptiste.C

Il faut absolument que je regarde précisément ce que je peux faire avec des variables déclarées buffer

Avec cette discussion, tu sais déjà le principal.
Il faut juste creuser un peu l'aide en ligne.

Envoyé par Baptiste.C

j'avoue que je suis allé au casse-pipe sans regarder la doc WD en me concentrant presque uniquement sur les API et la transcription de code C ou VB vers W langage.

De toute manière, je crois qu'on fait tous comme ça !

Et encore... bien heureux qu'il existe toute cette "littérature API" en C ou en VB.

Néanmoins, le VB est très limité pour les API: il manque certains types de données, il n'y a pas de déréférencement de pointeur.
Par conséquent, la programmation des API en VB contraint le développeur à de "mauvaises" pratiques.
Aussi, il vaudrait mieux s'inspirer d'exemples en C.

Cependant, comme le WLangage ne permet pas non plus de déréférencer les pointeurs, il faut parfois se battre avec les API à la façon de VB.
En clair: copier, modifier et recopier des blocs mémoires

.

C'est là que le Buffer WLangage peut être pratique pour la programmation des API, puisqu'il peut éviter certaines opérations de "copie mémoire".
_

(API) Utilisation de DocumentProperties() [WD14]

WinDev

Discussions similaires

Partager

Partager