self.Bind(wx.EVT_SIZE, self.OnSize) self.Bind(wx.EVT_BUTTON, self.OnButtonClick, theButton) -self.Bind(wx.EVT_MENU, self.OnExit, id=ID_EXIT) +self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT) ++
The wx.Menu methods that add items to a wx.Menu have been modified +such that they return a reference to the wx.MenuItem that was created. +Additionally menu items and toolbar items have been modified to +automatically generate a new ID if -1 is given, similar to using -1 +with window classess. This means that you can create menu or toolbar +items and event bindings without having to predefine a unique menu ID, +although you still can use IDs just like before if you want. For +example, these are all equivallent other than ID values:
++1. + item = menu.Append(-1, "E&xit", "Terminate the App") + self.Bind(wx.EVT_MENU, self.OnExit, item) + +2. + item = menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App") + self.Bind(wx.EVT_MENU, self.OnExit, item) + +3. + menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App") + self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT)-
I hope to be able to remove the need for using IDs even for menu -events too...
If you create your own custom event types and EVT_* functions, and you want to be able to use them with the Bind method above then you should change your EVT_* to be an instance of wxPyEventBinder instead of a @@ -260,13 +279,14 @@ SetClippingRegion(point, size) SetClippingRect(rect) SetClippingRegionAsRegion(region); -
If you have code that draws on a DC you will get errors because of -these changes, but it should be easy to fix the code. You can either -change the name of the Type B method called to the names shown -above, or just add parentheses around the parameters as needed to turn -them into tuples and let the SWIG typemaps turn them into the wx.Point -or wx.Size object that is expected. Then you will be calling the new -Type A method. For example, if you had this code before:
+If you have code that draws on a DC and you are using the new wx +namespace then you will get errors because of these changes, but +it should be easy to fix the code. You can either change the name of +the Type B method called to the names shown above, or just add +parentheses around the parameters as needed to turn them into tuples +and let the SWIG typemaps turn them into the wx.Point or wx.Size +object that is expected. Then you will be calling the new Type A +method. For example, if you had this code before:
dc.DrawRectangle(x, y, width, height)@@ -284,6 +304,14 @@ dc.DrawRectangle(p.x, p.y, s.width, s.height)
dc.DrawRectangle(p, s)+
Now before you start yelling and screaming at me for breaking all your +code, take note that I said above "...using the new wx namespace..." +That's because if you are still importing from wxPython.wx then there +are some classes defined there with Draw and etc. methods that have +2.4 compatible signatures. However if/when the old wxPython.wx +namespace is removed then these classes will be removed too so you +should plan on migrating to the new namespace and new DC Draw methods +before that time.
The hack allowing the old "option" keyword parameter has been -removed. If you use keyworkd args with wxSizer Add, Insert, or -Prepend then you will need to use the "proportion" name instead of -"option".
+The hack allowing the old "option" keyword parameter has been removed. +If you use keyworkd args with wxSizer Add, Insert, or Prepend methods +then you will need to use the "proportion" name instead of "option".
When adding a spacer to a sizer you now need to use a wxSize or a 2-integer sequence instead of separate width and height parameters.
The wxGridBagSizer class (very similar to the RowColSizer in the @@ -339,12 +366,11 @@ wrappers will figure out what to do.
into a single extension module, the "core" module is now just a few extensions that are linked independently, and then merged together later into the main namespace via Python code. -Because of the above, the "internal" module names have changed, but -you shouldn't have been using them anyway so it shouldn't bother -you. ;-)
-The wxPython.help module no longer exists and the classes therein are -now part of the core module imported with wxPython.wx or the wx -package.
+Because of the above and also because of the way the new SWIG works, +the "internal" module names have changed, but you shouldn't have been +using them anyway so it shouldn't bother you. ;-)
+The help module no longer exists and the classes therein are now part +of the core module imported with wxPython.wx or the wx package.
wxPyDefaultPosition and wxPyDefaultSize are gone. Use the wxDefaultPosition and wxDefaultSize objects instead.
Similarly, the wxSystemSettings backwards compatibiility aliases for @@ -359,13 +385,15 @@ refreshed.
wxPyTypeCast has been removed. Since we've had the OOR (Original Object Return) for a couple years now there should be no need to use wxPyTypeCast at all.
+If you use the old wxPython package and wxPython.wx namespace then +there are compatibility aliases for much of the above items.
+The wxWave class has been renamed to wxSound, and now has a slightly +different API.