Remove(window) in wxPhoenix

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Remove(window) in wxPhoenix

Karsten Hilbert
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Remove(window) in wxPhoenix

Karsten Hilbert
On Thu, Apr 12, 2018 at 05:06:46PM +0200, Karsten Hilbert wrote:

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Remove(window) in wxPhoenix

Olivier Bélanger
In reply to this post by Karsten Hilbert
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()

2) 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 <[hidden email]> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Remove(window) in wxPhoenix

Karsten Hilbert
On Thu, Apr 12, 2018 at 11:33:03AM -0400, Olivier Bélanger wrote:

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Remove(window) in wxPhoenix

Robin Dunn


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.

Yep. In addition to removing itself from the sizer, there are several other housekeeping things done when a widget is destroyed.

--
Robin


--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Aw: Re: [wxPython-users] Remove(window) in wxPhoenix

Karsten Hilbert
> 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 ;-)  ?

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [wxPython-users] Remove(window) in wxPhoenix

Robin Dunn
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 ;-)  ?


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...")

-- 
Robin

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [wxPython-users] Remove(window) in wxPhoenix

Karsten Hilbert
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...")

Would it be manageable to have Sphinx generate links into the
source under each of the methods described in the docs ?

Regards,
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [wxPython-users] Remove(window) in wxPhoenix

Robin Dunn
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 ?


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.
 
--
Robin

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [wxPython-users] Remove(window) in wxPhoenix

Karsten Hilbert

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.

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [wxPython-users] Remove(window) in wxPhoenix

Mike Driscoll-2


On Mon, Apr 16, 2018, 2:28 PM Karsten Hilbert <[hidden email]> 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.

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

Mike

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.