+simple one instead. By default the setting is turned off (on wxMac
+only.) When run on OSX the Py* apps have a new item on the Options
+menu for controlling this setting if you would like to experiment with
+it.</p>
+<p>Updated wx.lib.calendar with many fixes and enhancements from Joerg
+"Adi" Sieker.</p>
+<p>Added wx.Display and wx.VideoMode.</p>
+<p>AppleEvents can be handled by overriding wx.App methods MacOpenFile,
+MacPrintFile, MacNewFile, and MacReopenApp.</p>
+<p>Added wx.PlatformInfo which is a tuple containing strings that
+describe the platform and build options of wxPython. See the
+MigrationGuide for more details.</p>
+<p>Created a new extension module "activex" from Lindsay Mathieson's
+newest <a class="reference" href="http://members.optusnet.com.au/~blackpaw1/wxactivex.html">wxActiveX</a> class. (The existing iewin module used an older
+version of this code, but only exposed the wxIEHtmlWin class.) This
+new module will (in theory ;-) ) allow you to host arbitrary ActiveX
+controls in a wx.Window, <strong>without</strong> requiring the use of the win32com
+and other PyWin32 modules! This should eliminate the cronic problems
+that have resulted from minor mismatches in how PyWin32 handles the
+GIL and tstate when making callbacks, etc. The older iewin module
+will be left in this release as the new stuff is not fully backwards
+compatible, but you should migrate your code to the new IEHtmlWindow
+in wx.lib.iewin, so the old one can be eventually removed.
+Additionally, I've always considered that the wx.lib.activexwrapper
+module is an ugly hack that I only included in the lib because I
+couldn't figure out anything better. Well now we have something that,
+if it isn't already, has the potential to be better. So consider
+migrating away from using activexwrapper as well. Please see the
+MigrationGuide for more details on using the new module.</p>
+<p>Floats are allowed again as function parameters where ints are expected.</p>
projects / wxWidgets.git / blobdiff