<div class="document" id="recent-changes-for-wxpython">
<h1 class="title">Recent Changes for wxPython</h1>
<div class="section" id="id1">
-<h1><a name="id1">2.5.2.0</a></h1>
+<h1><a name="id1">2.5.2.7</a></h1>
<p>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
flag was added that will cause the sizer to use the old behaviour in
that it will <em>not</em> 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.</p>
-<p>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.</p>
+(or the size the window was created with) will always be used. Please
+see the Sizers section in the Migration Guide for more details.</p>
<p>Added new MaskedEditControl code from Will Sadkin. The modules are
now locaed in their own sub-package, wx.lib.masked. Demos updated.</p>
<p>The changes that implemented the incompatible wx.DC methods in 2.5.1.5
with a more modern reimplementation.</p>
<p>Added a new version (0.8.3) of FloatCanvas from Chris Barker. It's now
in a subpackage of wx.lib.</p>
+<p>It is now possible to change the tab traversal order of controls on a
+panel or dialog. For details see the new MoveAfterInTabOrder and
+MoveBeforeInTabOrder methods of wx.Window.</p>
+<p>Applied (and heavily modified) a patch from Eugene
+<<a class="reference" href="mailto:svip123@fastmail.fm">svip123@fastmail.fm</a>> that allows the sample modules in the demo to be
+edited and reloaded, all from within the demo. You can switch back
+and forth between the default and your edited version, and any errors
+ocurring upon the reload are reported on the Demo tab.</p>
+<p>Added a menu item in the demo that will open a PyShell window that has
+the app and demo frame preloaded in the namespace. This is another
+good way to explore and play with the objects in the currently running
+sample. For example, load the Button sample and then do the following
+in the PyShell:</p>
+<pre class="literal-block">
+>>> b = frame.demoPage.GetChildren()[0]
+>>> for x in range(0, 500, 10):
+... b.Move((x, 50))
+... app.Yield(True)
+... wx.MilliSleep(10)
+</pre>
</div>
<div class="section" id="id2">
<h1><a name="id2">2.5.1.5</a></h1>
projects / wxWidgets.git / blobdiff