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/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
+ it is also available in wxWindows 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 on
- win9x with the stock python.exe and pythonw.exe executables.
- Instead I've had to rebuild the Python loaders linked with this
- MSLU library from Microsoft. I'd like to find a way to build
- wxWindows/wxPython such that this is not needed...
+ done by using a special library and DLL with the application
+ called MSLU, (Microsoft Layer for Unicode). It simply gets out of
+ the way if the app is run on an NT box, otherwise 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
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.
+
+Added OOR support for wxGridCellRenderer, wxGridCellEditor,
+wxGridCellAttr, wxGridCellAttrProvider, wxGridTableBase and their
+derived classes.
+
+Added wxImage.GetDataBuffer which returns an in-place edit buffer of
+the image data. (Patch #546009)
+
+Added a sample that shows how to embed wxPython in a wxWindows C++
+application.
+
+Added wxPyWindow and wxPyControl which are just like their wx
+counterparts except they allow some of the more common C++ virtual
+methods to be overridden in Python derived classes. The methods
+supported are:
+
+ DoMoveWindow
+ DoSetSize
+ DoSetClientSize
+ DoSetVirtualSize
+ DoGetSize
+ DoGetClientSize
+ DoGetPosition
+ DoGetVirtualSize
+ DoGetBestSize
+ InitDialog
+ TransferDataFromWindow
+ TransferDataToWindow
+ Validate
+ AcceptsFocus
+ AcceptsFocusFromKeyboard
+ GetMaxSize
-Bad news: The API for adding tools to toolbars has changed again.
-Good news: Toolbar tools can now have labels!
+ If there are other methods that should be supported please let me
+ know.
+
+Changed wxGenButton to derive from wxPyControl and overload
+DoGetBestSize and AcceptsFocus.
+
+Added wxArtProvider.
+
+Added wxCallAfter which is a helper function that registers a function
+(or any callable Python object) to be called once the next time there
+are no pending events. This is useful for when you need to do
+something but it can't be done during the current event handler. The
+implementation is very simple, see wxPython/wx.py.
+
+Fixed a boatload of reference leaks.
+
+Added a demo of using a sizer in a wxScrolledWindow, in effect
+creating a ScrolledPanel.
+
+Added a sample to the demo that shows how to use radio menu items, and
+other menu stuff.
+
+Added wxIEHtmlWin. This is essentially the same as using IE with the
+ActiveXWrapper already in the library, but it is implemented all in
+C++ and therefore does not need any of the modules from win32 all and
+so it is less fragile in the face of changes.
+
+Fixed the ActiveXWrapper problem. Looks like when the win32com
+modules make a "callback" that they (incorrectly, IMHO) allocate a
+transient thread state structure. Since wxPython is now saving
+tstates for it's own callbacks it ended up using garbage after
+win32com gots rid of the tstate...
-
2.3.2
-----
Added EVT_HELP, EVT_HELP_RANGE, EVT_DETAILED_HELP,
projects / wxWidgets.git / blobdiff