AW: Python2.6 + win32com crashes with unicode bug

[Stefan Schukat]

Hello Gerrit, 

there is no problem in the file, but in the description of the Visio API. The place where the error occurs is during the definition 
of the parameters of the corresponding Python methods. The information for the names comes from the typelibrary of visio. Probably there is a 
non english name inside the typelibrary (MS used native names in early Office products) which then could not decoded to a correct Python name. 
In my Version of Vsio OpenEx has two parameters called FileName and Flags. You have to look in your typelibrary, e.g. with OleView
http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en and check the parameters. 


Regards

	Stefan



-----Ursprüngliche Nachricht-----
Von: python-list-bounces+sschukat=dspace.de at python.org [mailto:python-list-bounces+sschukat=dspace.de at python.org] Im Auftrag von GerritM
Gesendet: Freitag, 30. Oktober 2009 18:00
An: Terry Reedy
Cc: python-list at python.org
Betreff: Re: Python2.6 + win32com crashes with unicode bug


Terry Reedy schreef:
> GerritM wrote:
>> I have automated image generation with Python, win32com and Visio5.0. 
>> This works well upto Python2.5 but fails with Python 2.6.
>> Short term solution is to return to 2.5 :-(.
>>
>> I have reproduced the bug below with a minimum of Python lines. Below 
>> the problem the working example from 2.5
>>
>> kind regards, Gerrit
>>
>> ---minimal session reproducing the bug---
>>
<..snip..>
>> d = v.Documents.OpenEx("D:/temp/test.vsd",8)
<...snip...>
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 
>> 52: ordinal not in range(128)
> 
> I suspect that 2.6 fixed the bug of allowing non-ascii chars when using 
> the ascii codec.  I would check to see if there is an 0x83 in 
> D:/temp/test.vsd
> 
<...snip...>
the string "D:/temp/test.vsd" itself does not contain any 
charactervalue>128:
 >>> for c in "D:/temp/test.vsd":
	print ord(c), " ",

68   58   47   116   101   109   112   47   116   101   115   116   46 
  118   115   100
(on my current Python 2.5 configuration)

The presumably binary file itself may contain any value, but I don't 
expect Python or win32com to do anything with the file content...

There are explanations on internet that Windows uses internally 2 
(incompatible) API's that cause poblems with Unicode based filenames. I 
do something like that to be the problem in Python 2.6

kind regards, Gerrit

-- 
http://mail.python.org/mailman/listinfo/python-list