data in Python source code, and the generated code now uses streams to
convert the image data to wxImage, wxBitmap, or wxIcon.
-Added wxPython.lib.rcsizer which contains RowColSizer. This sizer is
-based on code from Niki Spahiev and lets you specify a row and column
-for each item, as well as optional column or row spanning. Cells with
-no item assigned to it are just left blank. Stretchable rows or
-columns are specified and work the same as in wxFlexGridSizer.
+Added the wxPython.lib.rcsizer module which contains RowColSizer.
+This sizer is based on code from Niki Spahiev and lets you specify a
+row and column for each item, as well as optional column or row
+spanning. Cells with no item assigned to it are just left blank.
+Stretchable rows or columns are specified and work the same as in
+wxFlexGridSizer.
Updated XRCed from Roman Rolinsky
Upgraded wxSTC from Scintilla 1.40 to Scintilla 1.45
-***---***---***---***---***---***---***---***---***---***---***---
- UNICODE!
-
- wxWindows and wxPython can be compiled with unicode support
- enabled or disabled. Previous to wxPython 2.3.3 non-unicode mode
- was always used. Starting with 2.3.3 either mode is supported,
- but only if it is also available in wxWindow on the platform.
- Currently wxWindows only supports unicode on MS Windows platforms,
- but with the recent release of GTK+ 2.0 it is only a matter of
- time until it can be done on wxGTK (Linux and other unixes) as
- well.
-
- When unicode is enabled, then all functions and methods in
- wxPython that return a wxString from the C++ function will return
- a Python unicode object, and parameters to C++ functions/methods
- that expect a wxString can accept either a Python string or
- unicode object. If a string object is passed then it will be
- decoded into unicode using the converter pointed to by
- wxConvCurrent, which will use the default system encoding. If you
- need to use a string in some other encoding then you should
- convert it to unicode using the Python codecs first and then pass
- the unicode to the wxPython method.
-***---***---***---***---***---***---***---***---***---***---***---
+UNICODE!
+
+ wxWindows/wxPython can be compiled with unicode support enabled or
+ disabled. Previous to wxPython 2.3.3 non-unicode mode was always
+ used. Starting with 2.3.3 either mode is supported, but only if
+ it is also available in wxWindow on the platform. Currently
+ wxWindows only supports unicode on MS Windows platforms, but with
+ the recent release of GTK+ 2.0 it is only a matter of time until
+ it can be done on wxGTK (Linux and other unixes) as well.
+
+ Unicode works best on platforms in the NT branch of the Windows
+ family tree (NT, win2k, XP) but it is now also possible to use the
+ same unicode binaries on win95/98/ME platforms as well! This is
+ done by using a special library and DLL in the application called
+ MSLU, (Microsoft Layer for Unicode). It simply gets out of the
+ way if the app is run on an NT box, or if run on a win9x box it
+ loads a special DLL that provides the unicode versions of the
+ windows API. So far I have not been able to get this to work
+ perfectly on win9x. Most things work fine but wxTaskBarIcon for
+ example will cause a crash if used with the unicode build on
+ win95.
+
+ So how do you use it? It's very simple. When unicode is enabled,
+ then all functions and methods in wxPython that return a wxString
+ from the C++ function will return a Python unicode object, and
+ parameters to C++ functions/methods that expect a wxString can
+ accept either a Python string or unicode object. If a string
+ object is passed then it will be decoded into unicode using the
+ converter pointed to by wxConvCurrent, which will use the default
+ system encoding. If you need to use a string in some other
+ encoding then you should convert it to unicode using the Python
+ codecs first and then pass the unicode string to the wxPython
+ method.
+
+Added wxListCtrlAutoWidthMixin from Erik Westra.
+
+Added wxIconBundle and wxTopLevelWindow.SetIcons.
+
+Added wxLocale and wxEncodingConverter.
+
+A little black magic... When the C++ object (for a window or
+whatever) is deleted there is no way to force the Python shadow object
+to also be destroyed and clean up all references to it. This leads to
+crashes if the shadow object tries to call a method with the old C++
+pointer. The black magic I've done is to replace the __class__ in the
+Python instance object with a class that raises an exception whenever
+a method call (or other attribute access) is attempted. This works
+for any class that is OOR aware.
projects / wxWidgets.git / blobdiff