[python-win32] why do I get error 1804 from win32print.SetJob?

[Tim Roberts]

Glenn Linderman wrote:
>
> I looked at the win32print.cpp file. There were lots of 
> Python-internals stuff there that I don't really follow well. I didn't 
> see anything obviously wrong, but I got to wondering about the code 
> that builds the structure... it puts in UTF-8 text strings (which 
> would be same as ASCII in the cases I'm considering, but what if 
> someone has a non-ASCII printer name, or document file name, or ???). 
> And I'm sure the A version of the Windows API probably is happy with 
> ASCII, but does the 64-bit compilation call the A version of the 
> Windows API or the W version?

32 vs 64 makes no difference here.   SetJobA always expects 8-bit 
strings, SetJobW always expects 16-bit strings.  SetJob maps to one or 
the other based on the absence or presence of #define UNICODE.  The 
routines that convert Python strings to zero-terminated strings will do 
the right thing.


> And would the W version be happy with ASCII? Or would that produce an 
> 1804 error?

If you pass ASCII strings to the W API, it just means the strings are 
interpreted as garbage.  The name will not be found.  It shouldn't cause 
1804.

I went to ReactOS and looked at the source code for SetJob. 
ERROR_INVALID_DATATYPE is returned for exactly one reason: the pDatatype 
value is not in the valid list of datatypes for the print processor for 
this job.  There's no reason for that; your structure says "NT EMF 
1.008", which is almost always valid.

This had to work at some point.  All of these things get tested. I just 
don't know what would have changed.  If I get motivated (I've already 
spent too much time on this ;), I'll see if I can get your script to 
fail here.


> And then of course, I've no idea what compilation parameters were 
> used, either for your program (which works), or for win32print.cpp 
> (which maybe doesn't).

I built mine for non-Unicode.

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3980 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-win32/attachments/20181120/98f7d87a/attachment.bin>