I need some help with the design of a "dynamic" wxDialog.
The dialog window is divided into several sizers, the first contains a
wxComboBox. When choosing an entry from this wxComboBox, a second
sizer (RowColSizer) will be populated with some controls, the number
and type of which will depend on the selected ComboBox-Entry. That
works fine for the first selection: The wxDialog is enlarged to give
room for the new controls. But when I make another selection, I get an
error saying that some positions in the sizer are populated twice. It
is obvious that the sizer has to be cleared before I put in the new
controls. I checked the documentation and found the Remove-Method for
sizers. Unfortunately, this method seems only to be able to remove a
sizer completely (which is not want I want, because the sizer will be
repopulated in the next step, and I dont want to recreate it, because
the sizer has to keep its position in the dialog relative to the other
sizers) or to remove the item with the specified position (which is no
alternative as well, because the number of childs or controls in the
sizer will vary).
Now my question: is there a clearall-Method for sizers that removes
all the items in the sizer or is there a function to get the number of
childs in the sizer so that I could write something like
for i in range(sizer.GetNumberOfChildren()):
sizer.Remove(i)
That would help me a lot.
Thanks in advance
Piet
From http Thu May 20 10:40:40 2004
From: http (Paul Rubin)
Date: 20 May 2004 01:40:40 -0700
Subject: Python compilers?
References: <Qpaqc.2106$RL3.55810@news2.e.nsc.no>
<Lbgqc.2183$Hf.1280764@newshog.newsread.com>
<tyfu0yem07c.fsf@pcepsft001.cern.ch>
<mailman.49.1084890435.6949.python-list@python.org>
<HEyqc.132$Uq1.127@fe2.columbus.rr.com>
<7xad0581ax.fsf@ruckus.brouhaha.com>
<60dfb6f6.0405191354.2c04a105@posting.google.com>
<7xfz9vamfh.fsf@ruckus.brouhaha.com>
<38Yqc.166$eO6.128@fe2.columbus.rr.com>
Message-ID: <7x1xlf8p9z.fsf@ruckus.brouhaha.com>
Carl Banks <imbosol at aerojockey.invalid> writes:
The example above kills any attempt to turn a.bar() into a static
procedure call.
Of course it does--but it's one method. A compiler, if it's good,procedure call.
would only make the optization on methods named "bar", and it could
probably pare the number of possible classes it could happen to down
to only a few.
anytime, anywhere in the code. Maybe even in an eval.
I mean you could have a Turing nightmare on your hands, with all kinds
of crazy setattrs and execs and stuff, in both Python and Lisp, and
then there's not much a compiler could do but emit totally general
code. I assume Lisp compilers do this sometimes.
Lisp compilers might have to do that sometimes, but Python compilersof crazy setattrs and execs and stuff, in both Python and Lisp, and
then there's not much a compiler could do but emit totally general
code. I assume Lisp compilers do this sometimes.
would have to do it ALL the time. Psyco took one way out, basically
generating code at runtime and caching it for specific operand types,
but the result is considerable code expansion compared to precompilation.
