no tab traversal?

Lets see if I can get GG to accept an e-mail from me w/o the web interface. Thanks for the interest.

Brian

tabtst.py (3.29 KB)

···

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

One simple fix is to put the panel itself into a sizer. Add the
following four lines to the end of your __init__:

topSizer = wx.BoxSizer(wx.VERTICAL)
topSizer.Add(panel, 1, wx.EXPAND)
topSizer.Fit(self)
topSizer.Layout()

That worked for me on Windows XP, Python 2.5, wxPython 2.8.10.1
(unicode)

···

On Apr 23, 7:26 am, "Brian H. Toby" <Brian.T...@ANL.gov> wrote:

Lets see if I can get GG to accept an e-mail from me w/o the web interface. Thanks for the interest.

Brian

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

That worked! Thanks Mike and Cody.

Perhaps I should just quit with a working recipe, but I'd like to
understand this better.

With that change I have a frame, inside the frame is a sizer
(topSizer), inside that is a panel, inside the panel is a sizer
(mainSizer) and then I place the building blocks of my program as
sizers inside that. This is a bit convoluted, but I can certainly live
with it and it is a very small amount of code. I see lots of examples
that skip the sizer between the frame and panel, can anyone explain
why this structure is needed here or point me to a good link or
section of Rappin & Dunn to better understand this?

The use of .Layout and .Fit is also unclear to me. After playing
around, it seems to me I need to call the .Fit method for the top-
level sizer before the .Show is called for the frame, but all the
other calls to .Layout and .Fit are not needed. Can this be explained
somehow?

Brian

···

On Apr 23, 8:28 am, Mike Driscoll <kyoso...@gmail.com> wrote:

One simple fix is to put the panel itself into a sizer.

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

I’m not very good at explaining how that works, so I’ll use Robin’s words from his book:

“At the end, we call the Fit() method of the box sizer, with the control panel as an argument. The method tells the control panel to resize itself to match the minimum size that the sizer thinks it needs. Typically, you’ll call this method as part of the creation of a window that uses sizers, to ensure that the enclosing window is large enough to encompass the sizer.” - pg 177

or

"(optional) Enable the sizer to calculate its size. Tell the sizer to calculate its size based on its children by calling either the wx.Window method Fit() on the parent window object or the Fit(window) method of the sizer. (The window method redirects to the sizer method.) In either case, the Fit() method asks the sizer to calculate its size based on what it knows about its children, and it resizes the parent widget to fit. There is a related method, FitInside(), which does not change the display size of the parent widget, but does change its virtual size—meaning that if the widget is inside

a scrolled panel, wxPython would recalculate whether or not scroll bars are needed." - pg 326

Layout() - Programatically forces the sizer to recalculate the size and position of its children. Call after dynamically adding or removing a child. - pg 177

So it would seem that you call Layout() when you change the layout of the widgets onscreen (i.e. adding, deleting or rearranging widgets). I rarely call Fit as I have so many issues with it, but I think Robin once mentioned to me that putting the top panel in a sizer will help with some of these layout issues. Thus, when I run into problems like this and Layout or Refresh doesn’t take care of it, then I try putting the panel into a sizer. I’m sure Robin, Chris or Andrea will jump in with more coherent explanations.

···

On Fri, Apr 23, 2010 at 12:05 PM, bht brian.toby@anl.gov wrote:

On Apr 23, 8:28 am, Mike Driscoll kyoso...@gmail.com wrote:

One simple fix is to put the panel itself into a sizer.

That worked! Thanks Mike and Cody.

Perhaps I should just quit with a working recipe, but I’d like to

understand this better.

With that change I have a frame, inside the frame is a sizer

(topSizer), inside that is a panel, inside the panel is a sizer

(mainSizer) and then I place the building blocks of my program as

sizers inside that. This is a bit convoluted, but I can certainly live

with it and it is a very small amount of code. I see lots of examples

that skip the sizer between the frame and panel, can anyone explain

why this structure is needed here or point me to a good link or

section of Rappin & Dunn to better understand this?

The use of .Layout and .Fit is also unclear to me. After playing

around, it seems to me I need to call the .Fit method for the top-

level sizer before the .Show is called for the frame, but all the

other calls to .Layout and .Fit are not needed. Can this be explained

somehow?

Brian

Mike Driscoll

Blog: http://blog.pythonlibrary.org

To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com

or visit http://groups.google.com/group/wxPython-users?hl=en

One simple fix is to put the panel itself into a sizer.

That worked! Thanks Mike and Cody.

Perhaps I should just quit with a working recipe, but I'd like to
understand this better.

The problem in this case was caused by doing a layout before the sizer had been assigned to the panel, while the panel was still sized at its small initial size, and with all the content using center alignment. So half the widgets got shifted over to negative coordinates to compensate for the small size. Moving the "panel.SetSizer(mainSizer)" line up to before the Fit and Layout will solve this.

With that change I have a frame, inside the frame is a sizer
(topSizer), inside that is a panel, inside the panel is a sizer
(mainSizer) and then I place the building blocks of my program as
sizers inside that. This is a bit convoluted, but I can certainly live
with it and it is a very small amount of code. I see lots of examples
that skip the sizer between the frame and panel, can anyone explain
why this structure is needed here or point me to a good link or
section of Rappin& Dunn to better understand this?

The main advantage of also putting the panel in a sizer that is assigned to the frame is that then you can just do a frame.Fit() and in the process of evaluating the sizer assigned to the frame it will end up also evaluating the panel's sizer and so on.

The use of .Layout and .Fit is also unclear to me. After playing
around, it seems to me I need to call the .Fit method for the top-
level sizer before the .Show is called for the frame, but all the
other calls to .Layout and .Fit are not needed. Can this be explained
somehow?

Layout runs the sizer's algorithm and resizes and positions the managed items within the space currently available to it. Fit also runs the algorithm but just to calculate the minimum size to show everything, and then resizes the window to that size, and then in the size event that happens from that resize Layout will be called like normal.

···

On 4/23/10 10:05 AM, bht wrote:

On Apr 23, 8:28 am, Mike Driscoll<kyoso...@gmail.com> wrote:

--
Robin Dunn
Software Craftsman

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en