(API) Utilisation de DocumentProperties()

Version imprimable

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:

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

22/04/2010, 19h54
=JBO=
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.
_

Merci pour cette réponse rapide !

Citation:

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:

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

Citation:

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 ?

Merci pour tes précisions. :ccool:

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 :ccool:) utiles pour définir la structure DEVMODE ou pour appeler l'API.
Code:

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
Citation:

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

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:

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

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

Code:

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

22/04/2010, 22h02
Baptiste.C

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 ! :ccool:
22/04/2010, 22h14
=JBO=

Citation:

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

Citation:

Envoyé par Baptiste.C

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

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 !
_
22/04/2010, 22h21
Baptiste.C

Je me souviendrai de tes précieux conseils, JBO ! 8-)
22/04/2010, 22h32
=JBO=

Bon courage pour la programmation de l'imprimante via les API...
Ce n'est pas toujours très simple... N'est-ce pas ?! ;)
_
22/04/2010, 22h38
Baptiste.C

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 :mrgreen:
22/04/2010, 22h58
=JBO=

Citation:

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. :ccool:

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.
_
22/04/2010, 23h08
Baptiste.C

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. :roll:
23/04/2010, 00h07
=JBO=

Citation:

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.

Citation:

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. :roll:

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 :roll:.

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".
_