unicode compatibility

General question:

I’ve been working entirely with non-unicode builds because we’re using Boost.Python extensively in our app, and it doesn’t handle unicode objects properly. Since my impression is that Unicode is the way of the future as far as wxPython is concerned, and all of the pre-built packages are Unicode, I’m considering refactoring my wxPython-specific code to work independently of the string type used. However, it isn’t clear to me what this would require. Obviously a first step would be doing things like this:

val = str(text_ctrl.GetValue())

but does SWIG handle the reverse conversion automatically, i.e. can I do the following in a unicode build:

text_ctrl.SetValue(str(val))

choice_ctrl.SetItems([“foo”, “bar”, “other”])

Are there any other limitations or incompatibilities I need to be aware of?

thanks,

Nat

See http://wiki.wxpython.org/UnicodeBuild

···

On 11/14/10 10:42 AM, Nat Echols wrote:

General question:

I've been working entirely with non-unicode builds because we're using
Boost.Python extensively in our app, and it doesn't handle unicode
objects properly. Since my impression is that Unicode is the way of the
future as far as wxPython is concerned, and all of the pre-built
packages are Unicode, I'm considering refactoring my wxPython-specific
code to work independently of the string type used. However, it isn't
clear to me what this would require. Obviously a first step would be
doing things like this:

val = str(text_ctrl.GetValue())

but does SWIG handle the reverse conversion automatically, i.e. can I do
the following in a unicode build:

text_ctrl.SetValue(str(val))
choice_ctrl.SetItems(["foo", "bar", "other"])

Are there any other limitations or incompatibilities I need to be aware of?

--
Robin Dunn
Software Craftsman
http://wxPython.org