]> git.saurik.com Git - wxWidgets.git/blobdiff - wxPython/docs/MigrationGuide.html
added tech note about writing unit tests
[wxWidgets.git] / wxPython / docs / MigrationGuide.html
index d6b33f9cf1ceb0add0783417705b40e2ad37a069..8b8b19c86ab3f7a7e66a8f0f0d91c7423787d207 100644 (file)
@@ -100,10 +100,29 @@ def Bind(self, event, handler, source=None, id=wxID_ANY, id2=wxID_ANY):
 <pre class="literal-block">
 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)
+</pre>
+<p>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:</p>
+<pre class="literal-block">
+1.
+  item = menu.Append(-1, &quot;E&amp;xit&quot;, &quot;Terminate the App&quot;)
+  self.Bind(wx.EVT_MENU, self.OnExit, item)
+
+2. 
+  item = menu.Append(wx.ID_EXIT, &quot;E&amp;xit&quot;, &quot;Terminate the App&quot;)
+  self.Bind(wx.EVT_MENU, self.OnExit, item)
+
+3. 
+  menu.Append(wx.ID_EXIT, &quot;E&amp;xit&quot;, &quot;Terminate the App&quot;)
+  self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT)
 </pre>
-<p>I hope to be able to remove the need for using IDs even for menu
-events too...</p>
 <p>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);
 </pre>
-<p>If you have code that draws on a DC you <strong>will</strong> get errors because of
-these changes, but it should be easy to fix the code.  You can either
-change the name of the <em>Type B</em> 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
-<em>Type A</em> method.  For example, if you had this code before:</p>
+<p>If you have code that draws on a DC and you are using the new wx
+namespace then you <strong>will</strong> get errors because of these changes, but
+it should be easy to fix the code.  You can either change the name of
+the <em>Type B</em> 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 <em>Type A</em>
+method.  For example, if you had this code before:</p>
 <pre class="literal-block">
 dc.DrawRectangle(x, y, width, height)
 </pre>
@@ -284,6 +304,14 @@ dc.DrawRectangle(p.x, p.y, s.width, s.height)
 <pre class="literal-block">
 dc.DrawRectangle(p, s)
 </pre>
+<p>Now before you start yelling and screaming at me for breaking all your
+code, take note that I said above &quot;...using the new wx namespace...&quot;
+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.</p>
 </div>
 <div class="section" id="building-extending-and-embedding-wxpython">
 <h1><a name="building-extending-and-embedding-wxpython">Building, Extending and Embedding wxPython</a></h1>
@@ -320,10 +348,9 @@ class MyDialog(wx.Dialog):
 </div>
 <div class="section" id="sizers">
 <h1><a name="sizers">Sizers</a></h1>
-<p>The hack allowing the old &quot;option&quot; keyword parameter has been
-removed.  If you use keyworkd args with wxSizer Add, Insert, or
-Prepend then you will need to use the &quot;proportion&quot; name instead of
-&quot;option&quot;.</p>
+<p>The hack allowing the old &quot;option&quot; keyword parameter has been removed.
+If you use keyworkd args with wxSizer Add, Insert, or Prepend methods
+then you will need to use the &quot;proportion&quot; name instead of &quot;option&quot;.</p>
 <p>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.</p>
 <p>The wxGridBagSizer class (very similar to the RowColSizer in the
@@ -339,12 +366,11 @@ wrappers will figure out what to do.</p>
 into a single extension module, the &quot;core&quot; module is now just a few
 extensions that are linked independently, and then merged together
 later into the main namespace via Python code.</p>
-<p>Because of the above, the &quot;internal&quot; module names have changed, but
-you shouldn't have been using them anyway so it shouldn't bother
-you. ;-)</p>
-<p>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.</p>
+<p>Because of the above and also because of the way the new SWIG works,
+the &quot;internal&quot; module names have changed, but you shouldn't have been
+using them anyway so it shouldn't bother you. ;-)</p>
+<p>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.</p>
 <p>wxPyDefaultPosition and wxPyDefaultSize are gone.  Use the
 wxDefaultPosition and wxDefaultSize objects instead.</p>
 <p>Similarly, the wxSystemSettings backwards compatibiility aliases for
@@ -359,13 +385,15 @@ refreshed.</p>
 <p>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.</p>
+<p>If you use the old wxPython package and wxPython.wx namespace then
+there are compatibility aliases for much of the above items.</p>
+<p>The wxWave class has been renamed to wxSound, and now has a slightly
+different API.</p>
 </div>
 </div>
 <hr class="footer" />
 <div class="footer">
-<a class="reference" href="MigrationGuide.txt">View document source</a>.
-Generated on: 2003-12-23 21:34 UTC.
-Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+Generated on: 2004-02-04 23:31 UTC.
 </div>
 </body>
 </html>