A few days ago Andy made the following change to the
resourceOutput.py module.
*** resourceOutput.py 27 Oct 2005 22:58:00 -0000 1.33
--- resourceOutput.py 3 Mar 2006 10:07:21 -0000 1.34
***************
*** 95,100 ****
#print key, value, type(value)
if isinstance(value, (str, unicode)):
! if isinstance(value, unicode):
! value = value.encode('ascii', 'ignore')
# need to escape strings
#pprint.pprint(value)
--- 95,100 ----
#print key, value, type(value)
if isinstance(value, (str, unicode)):
! # if isinstance(value, unicode):
! # value = value.encode('ascii', 'ignore')
# need to escape strings
#pprint.pprint(value)
I don't remember all the issues we have with regards to unicode but I
know we need more testing. The hack which Andy commented out means
that if someone is running a unicode version of wxPython, all strings
that come from a wxPython widget will be saved to the .rsrc.py file
as a unicode string instead of a plain ascii string:
'text':u'TextField1'
instead of
'text':'TextField1'
In order to support unicode that is probably the right answer, but we
need some testing now. I saved a simplistic .rsrc.py file via the
resourceEditor using a unicode build of wxPython and then switched to
an ansi build by changing the wx.pth file in site-packages and
confirmed that for the simple case an ansi version of wxPython
doesn't cause PythonCard to break when it tries to load a 7-bit ascii
string. However, we need some tests where the unicode string(s) in
the .rsrc.py file don't translate to 7-bit ascii so we can fail
gracefully or convert in a sensible manner.
Doing a search for \:u\' using findfiles returned only the
standaloneBuilder resource files as having a unicode string but the
text is just 7-bit ascii. If anyone can make some test .rsrc.py files
that we can use to break PythonCard and fix issues that would be great.
ka
|
