X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/82a074ce2b5dcc6343873e3c458685d5fe903305..4f09729dfb63907ee07fc9395ff47f6411eb7469:/wxPython/docs/MigrationGuide.txt

diff --git a/wxPython/docs/MigrationGuide.txt b/wxPython/docs/MigrationGuide.txt
index 70c968ada1..c2a63f8326 100644
--- a/wxPython/docs/MigrationGuide.txt
+++ b/wxPython/docs/MigrationGuide.txt
@@ -107,11 +107,31 @@ Some examples of its use::
 
      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)
-     
-I hope to be able to remove the need for using IDs even for menu
-events too...
+     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)
+
+     
 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
@@ -132,6 +152,8 @@ number of IDs that are needed to be passed to Connect.
 
 
 
+
+
 The wx Namespace
 ----------------
 
@@ -281,13 +303,14 @@ that are affected are listed here::
     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)
 
@@ -305,6 +328,14 @@ Then you can just simplify it like this::
 
     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.
 
 
 
@@ -352,10 +383,9 @@ For example::
 Sizers
 ------
 
-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.
@@ -378,13 +408,12 @@ 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. ;-)
+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 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.
+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.
@@ -405,3 +434,8 @@ 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.