+wrappers will figure out what to do. **[Changed in 2.5.2.0]**
+AddWindow, AddSize, AddSpacer and etc. will now issue a
+DeprecationWarning.
+
+**[Changed in 2.5.2.0]** wx.ADJUST_MINSIZE is now the default
+behaviour for window items in sizers. This means that the item's
+GetMinSize and/or GetBestSize will be called when calculating layout
+and the return value from that will be used for the minimum size used
+by the sizer. The wx.FIXED_MINSIZE flag was added that will cause the
+sizer to use the old behaviour in that it will *not* call the window's
+methods to determine the new best size, instead the minsize that the
+window had when added to the sizer (or the size the window was created
+with) will always be used.
+
+Related to the above, when controls and some other window types are
+created either the size passed to the constructor, or their "best
+size" if an explicit size was not passed in, is set as the window's
+minimal size. For non top-level windows that hasn't meant much in the
+past, but now the sizers are sensitive to the window's minimal size.
+The key point to understand here is that it is no longer the window's
+size it has when added to the sizer that matters, but its minimal
+size. So you might have some issues to iron out if you create a
+control without a size and then set its size to something before
+adding it to the sizer. Since it's minimal size is probably not the
+size you set then the sizer will appear to be misbehaving. The fix is
+to either set the size when calling the window's constructor, or to
+reset the min size by calling SetSizeHints. You can call SetSizeHints
+at anytime to change the minsize of a window, just call the sizer's
+Layout method to redistribute the controls as needed.
+
+
+
+PlatformInfo
+------------
+
+Added wx.PlatformInfo which is a tuple containing strings that
+describe the platform and build options of wxPython. This lets you
+know more about the build than just the __WXPORT__ value that
+wx.Platform contains, such as if it is a GTK2 build. For example,
+instead of::
+
+ if wx.Platform == "__WXGTK__":
+ ...
+
+you should do this::
+
+ if "__WXGTK__" in wx.PlatformInfo:
+ ...
+
+and you can specifically check for a wxGTK2 build by looking for
+"gtk2" in wx.PlatformInfo. Unicode builds are also detectable this
+way. If there are any other platform/toolkit/build flags that make
+sense to add to this tuple please let me know.
+
+BTW, wx.Platform will probably be deprecated in the future.
+
+
+
+ActiveX
+-------
+
+Lindsay Mathieson's newest wxActiveX_ class has been wrapped into a new
+extension module called wx.activex. It is very generic and dynamic
+and should allow hosting of arbitray ActiveX controls within your
+wxPython apps. So far I've tested it with IE, PDF, and Flash
+controls, (and there are new samples in the demo and also library
+modules supporting these.)
+
+.. _wxActiveX: http://members.optusnet.com.au/~blackpaw1/wxactivex.html
+
+The new wx.activex module contains a bunch of code, but the most
+important things to look at are ActiveXWindow and ActiveXEvent.
+ActiveXWindow derives from wxWindow and the constructor accepts a
+CLSID for the ActiveX Control that should be created. (There is also
+a CLSID class that can convert from a progID or a CLSID String.) The
+ActiveXWindow class simply adds methods that allow you to query some
+of the TypeInfo exposed by the ActiveX object, and also to get/set
+properties or call methods by name. The Python implementation
+automatically handles converting parameters and return values to/from
+the types expected by the ActiveX code as specified by the TypeInfo,
+(just bool, integers, floating point, strings and None/Empty so far,
+but more can be handled later.)
+
+That's pretty much all there is to the class, as I mentioned before it
+is very generic and dynamic. Very little is hard-coded and everything
+that is done with the actual ActiveX control is done at runtime and
+referenced by property or method name. Since Python is such a dynamic
+language this is a very good match. I thought for a while about doing
+some Python black-magic and making the specific methods/properties of
+the actual ActiveX control "appear" at runtime, but then decided that
+it would be better and more understandable to do it via subclassing.
+So there is a utility class in wx.activex that given an existing
+ActiveXWindow instance can generate a .py module containing a derived
+class with real methods and properties that do the Right Thing to
+reflect those calls to the real ActiveX control. There is also a
+script/tool module named genaxmodule that given a CLSID or progID and
+a class name, will generate the module for you. There are a few
+examples of the output of this tool in the wx.lib package, see
+iewin.py, pdfwin.py and flashwin.py.
+
+Currently the genaxmodule tool will tweak some of the names it
+generates, but this can be controled if you would like to do it
+differently by deriving your own class from GernerateAXModule,
+overriding some methods and then using this class from a tool like
+genaxmodule. [TODO: make specifying a new class on genaxmodule's
+command-line possible.] The current default behavior is that any
+event names that start with "On" will have the "On" dropped, property
+names are converted to all lower case, and if any name is a Python
+keyword it will have an underscore appended to it. GernerateAXModule
+does it's best when generating the code in the new module, but it can
+only be as good as the TypeInfo data available from the ActiveX
+control so sometimes some tweaking will be needed. For example, the
+IE web browser control defines the Flags parameter of the Navigate2
+method as required, but MSDN says it is optional.
+
+It is intended that this new wx.activex module will replace both the
+older version of Lindsay's code available in iewin.IEHtmlWindow, and
+also the wx.lib.activexwraper module. Probably the biggest
+differences you'll ecounter in migrating activexwrapper-based code
+(besides events working better without causing deadlocks) is that
+events are no longer caught by overriding methods in your derived
+class. Instead ActiveXWindow uses the wx event system and you bind
+handlers for the ActiveX events exactly the same way you do for any wx
+event. There is just one extra step needed and that is creating an
+event ID from the ActiveX event name, and if you use the genaxmodule
+tool then this extra step will be handled for you there. For example,
+for the StatusTextChange event in the IE web browser control, this
+code is generated for you::
+
+ wxEVT_StatusTextChange = wx.activex.RegisterActiveXEvent('StatusTextChange')
+ EVT_StatusTextChange = wx.PyEventBinder(wxEVT_StatusTextChange, 1)
+
+and you would use it in your code like this::
+
+ self.Bind(iewin.EVT_StatusTextChange, self.UpdateStatusText, self.ie)
+
+When the event happens and your event handler function is called the
+event properties from the ActiveX control (if any) are converted to
+attributes of the event object passed to the handler. (Can you say
+'event' any more times in a single sentence? ;-) ) For example the
+StatusTextChange event will also send the text that should be put into
+the status line as an event parameter named "Text" and you can access
+it your handlers as an attribute of the event object like this::
+
+ def UpdateStatusText(self, evt):
+ self.SetStatusText(evt.Text)
+
+Usually these event object attributes should be considered read-only,
+but some will be defined by the TypeInfo as output parameters. In
+those cases if you modify the event object's attribute then that value
+will be returned to the ActiveX control. For example, to prevent a
+new window from being opened by the IE web browser control you can do
+this in the handler for the iewin.EVT_NewWindow2 event::
+
+ def OnNewWindow2(self, evt):
+ evt.Cancel = True
+
+So how do you know what methods, events and properties that an ActiveX
+control supports? There is a funciton in wx.activex named GetAXInfo
+that returns a printable summary of the TypeInfo from the ActiveX
+instance passed in. You can use this as an example of how to browse
+the TypeInfo provided, and there is also a copy of this function's
+output appended as a comment to the modules produced by the
+genaxmodule tool. Beyond that you'll need to consult the docs
+provided by the makers of the ActiveX control that you are using.
+
+
+
+OGL is dead! LONG LIVE OGL!
+---------------------------
+
+**[Changed in 2.5.2.0]**
+
+The wx.ogl module has been deprecated in favor of the new Python port
+of the OGL library located at wx.lib.ogl contributed by Pierre Hjälm.
+This will hopefully greatly extend the life of OGL within wxPython by
+making it more easily maintainable and less prone to getting rusty as
+there seems to be less and less interest in maintaining the C++
+version.
+
+There are only a few known compatibility issues at this time. First
+is the location of OGL. The deprecated version is located in the
+wx.ogl module, and the new version is in the wx.lib.ogl package. So
+this just means that to start using the new version you need to adjust
+your imports. So if your code currently has something like this::
+
+ import wx
+ import wx.ogl as ogl
+
+Then just change it to this::
+
+ import wx
+ import wx.lib.ogl as ogl
+
+The other compatibility issue deals with removing a wart in the
+original API that was necessary in order to allow overloaded methods
+in derived classes to call the same method in the base class when
+using the old SWIG. Instead dedaling with the wart you can now just
+call the base class method like you woudl for any other Python class.
+For example, if you had to do something like this previously::
+
+ class MyDividedShape(ogl.DividedShape):
+ ...
+ def OnSizingEndDragLeft(self, pt, x, y, keys, attch):
+ self.base_OnSizingEndDragLeft(pt, x, y, keys, attch)
+ ...
+
+You will need to change it to be like this::
+
+ class MyDividedShape(ogl.DividedShape):
+ ...
+ def OnSizingEndDragLeft(self, pt, x, y, keys, attch):
+ ogl.DividedShape.OnSizingEndDragLeft(self, pt, x, y, keys, attch)
+ ...
+
+
+
+Obsolete Modules
+----------------
projects / wxWidgets.git / blobdiff