Remove(window) in wxPhoenix

Hi,

I am dynamically removing a Panel from a Sizer. In wxp3 it
was possible to do

  szr.Remove(the_panel)

which wxp4 does not offer anymore. In wxp4 there are:

  Remove(index_of_a_child_window_of_the_sizer)
  Remove(a_child_sizer)

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

···

--

I am dynamically removing a Panel from a Sizer. In wxp3 it
was possible to do

  szr.Remove(the_panel)

which wxp4 does not offer anymore. In wxp4 there are:

  Remove(index_of_a_child_window_of_the_sizer)
  Remove(a_child_sizer)

...

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

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:
--

IHi,

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:

  1. 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()

  1. 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:

the_panel.Destroy()

szr.Layout()

Olivier

···

On Thu, Apr 12, 2018 at 11:06 AM, Karsten Hilbert Karsten.Hilbert@gmx.net wrote:

Hi,

I am dynamically removing a Panel from a Sizer. In wxp3 it

was possible to do

    szr.Remove(the_panel)

which wxp4 does not offer anymore. In wxp4 there are:

    Remove(index_of_a_child_window_of_the_sizer)

    Remove(a_child_sizer)

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.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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.

Robin

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 :wink: ?

Karsten

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 :wink: ?

Robin

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 :wink: ?
>
>
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 ?

Robin

I see. Thanks.

Karsten

···

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.

--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

You could always do a PR on the documentation or add it to the wiki. That would be a start.

Mike

···

On Mon, Apr 16, 2018, 2:28 PM Karsten Hilbert Karsten.Hilbert@gmx.net wrote:

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.

I see. Thanks.