From: Kevin A. <al...@se...> - 2006-03-10 21:16:07
|
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 |