Both of which do not fit the bill when I want to make the
above .Remove() call robust against changes to future changes
in the layout.
Now, I would have thought there's a way to get the index
position by doing
szr.GetItem(the_panel).some_property_or_method
but it seems there's no such property on wx.SizerItem.
Neither can I find a
FindIndexByWindow()
such that
szr.Remove(szr.FindIndexByWindow(the_panel))
would work.
I can see three options:
- remember the index from when the_panel gets Add()ed
- add an extra sizer around the_panel so the index is known constant 0
- loop over children of the sizer and compare against the_panel
- remember the index from when the_panel gets Add()ed
- add an extra sizer around the_panel so the index is known constant 0
- loop over children of the sizer and compare against the_panel
Coming from the Dept. of Second Thoughts, I would have had to
know the index _already_ for properly positioned _injection_
of a new Panel into the sizer (which was the whole point of
remove the_panel in the first place) except for two
happenstances:
- I already had a dedicated sizer around the_panel
thusly, the index is know to be 0
- the_panel was the only item of the sizer
thusly, just Add()ing another panel would
end up in the same place: appended to -
nothing before it
However, apart from lucky circumstances for me, the basic
question remains.
Karsten
···
On Thu, Apr 12, 2018 at 05:06:46PM +0200, Karsten Hilbert wrote:
--
just faced this problem lately when porting an old app to phoenix. You can do two things, depending on what you want to do with your window after removing it from the sizer:
If you don’t want to destroy the window, call Detach() and Layout() to force the layout of sizer’s children:
szr.Detach(the_panel)
szr.Layout()
If you want the window to be destroyed (which is what .Remove() did in classic), destroy the window and Layout() to force the layout of sizer’s children:
Both of which do not fit the bill when I want to make the
above .Remove() call robust against changes to future changes
in the layout.
Now, I would have thought there’s a way to get the index
position by doing
szr.GetItem(the_panel).some_property_or_method
but it seems there’s no such property on wx.SizerItem.
Neither can I find a
FindIndexByWindow()
such that
szr.Remove(szr.FindIndexByWindow(the_panel))
would work.
I can see three options:
- remember the index from when the_panel gets Add()ed
- add an extra sizer around the_panel so the index is known constant 0
- loop over children of the sizer and compare against the_panel
neither of which is particulary appealing.
Are there better suggestions ?
Perhaps I am just missing the obvious ?
Thanks,
Karsten
–
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
just faced this problem lately when porting an old app to phoenix.
Same here.
You can do two things, depending on what you want to do with your window after
removing it from the sizer:
2) If you want the window to be destroyed
+1
(which is what .Remove() did in classic),
AFAICT only for child sizers, not for windows, which were
cautioned to have a need for manual Destroy() after being
.Remove()d -- which my old code does do: .Remove(), then
.Destroy().
destroy the window and Layout() to force the layout of sizer's
children:
the_panel.Destroy()
szr.Layout()
Ha ! And that would safely Remove() it from a containing
sizer implicitely ?
And, indeed, while the wxPhoenix Destroy() docs don't say
anything on that matter, the docs for SetContainingSizer()
most certainly do:
SetContainingSizer(self, sizer)¶
...
It is called when a window is added to a sizer, and
is used so the window can remove itself from the
sizer when it is destroyed.
Thanks heaps !
Karsten
···
On Thu, Apr 12, 2018 at 11:33:03AM -0400, Olivier Bélanger wrote:
--
Yep. In addition to removing itself from the sizer, there are several other housekeeping things done when a widget is destroyed.
···
On Thursday, April 12, 2018 at 8:42:09 AM UTC-7, Karsten Hilbert wrote:
Ha ! And that would safely Remove() it from a containing
sizer implicitely ?
And, indeed, while the wxPhoenix Destroy() docs don’t say
anything on that matter, the docs for SetContainingSizer()
most certainly do:
SetContainingSizer(self, sizer)ś
...
It is called when a window is added to a sizer, and
is used so the window can remove itself from the
sizer when it is destroyed.
Not that I can think of. There are probably tidbits scattered all over, but the only consolodated source of info like this that I can think of is the source. (Hmm… sounds like a philosophy discussion of some sort… “The source is the source is the…”)
···
On Thursday, April 12, 2018 at 1:22:59 PM UTC-7, Karsten Hilbert wrote:
Yep. In addition to removing itself from the sizer, there are several other housekeeping things done when a widget is destroyed.
Thanks. Can I read up on this someplace (other than the source ?
Would it be manageable to have Sphinx generate links into the
source under each of the methods described in the docs ?
Regards,
Karsten
···
On Fri, Apr 13, 2018 at 08:55:44AM -0700, Robin Dunn wrote:
> > Yep. In addition to removing itself from the sizer, there are several
> other housekeeping things done when a widget is destroyed.
>
> Thanks. Can I read up on this someplace (other than the source ?
>
>
Not that I can think of. There are probably tidbits scattered all over, but
the only consolodated source of info like this that I can think of is the
source. (Hmm... sounds like a philosophy discussion of some sort... "The
source is the source is the...")
Unlikely. Many of them would require multiple links into the C++ code as there are both common and platform-specific implementations that would be involved.
···
On Saturday, April 14, 2018 at 2:43:18 AM UTC-7, Karsten Hilbert wrote:
Would it be manageable to have Sphinx generate links into the
source under each of the methods described in the docs ?
On Mon, Apr 16, 2018 at 08:55:20AM -0700, Robin Dunn wrote:
> Would it be manageable to have Sphinx generate links into the
> source under each of the methods described in the docs ?
Unlikely. Many of them would require multiple links into the C++ code as
there are both common and platform-specific implementations that would be
involved.