Unexpected wxSizer::Detach Behavior

[Kafrene Trading]

Hello,

I’m a bit confused on the intended usage of wxSizer::Detach. The documentation (for the index variant) reads

Detach an item at position index from the sizer without destroying it.

Which reads as though “it” refers to item, and item refers to the wxSizerItem. However, looking at the code for wxSizer::Detach, it is clear the item is, in fact, deleted.

The window or sizer, if the item “held” one, is not destroyed, but the item itself is, which is surprising to me, since items can be more than just windows or sizers.

Ultimately this is something of an x-y problem: The actual goal I’d like to accomplish is being able to remove an item from the sizer, and then re-inserting it either immediately or at a later time, maybe hiding it for a while in the latter case.

It’s not obvious how to accomplish this, afaics. I’d like to preserve any item attributes (size, border, align, etc.) and maintain abstraction over the underlying kind.

I suppose I could check the kind and copy everything manually, but that feels less than ideal to have in application code.

Is there a better way to do this rather than copying the sizer item attributes, detaching, creating a new item with those attributes, then inserting? If not, would a PR for something like this (“Detach”, though maybe by a different name given the different behavior, which accepts a sizer item and does the detach without deleting the item) make sense?

Thank you,

Ryan Ogurek

[jon bird]

Hi Ryan,

Not sure I have a specific answer to the question you posed however I
do use this to accomplish (I think) something like what you're after.
In my app, there are two columns of 10 buttons in a wxAUI dock - see
image here:

https://www.onasticksoftware.co.uk/about.html

when un-docked, I wanted to re-arrange them into a 4x3 grid (also noting
that allows for an extra 2 buttons):

https://www.oasw.co.uk/public/bwall-move.png

I've accomplished this by detaching the existing sizers and rearranging
everything - here's the code fragment which does this:

https://www.oasw.co.uk/public/bwall-resize.cpp

There's a fair bit to it but the essence is I think based around what
you're talking about.

This works nicely under Windows however on Linux, when the window is
re-docked, it crashes somewhere in the gtk layer. Suspect I'm doing
something subtly (or completely) wrong in there somewhere however I've
not found the time to do anything about it.

Rgs,

Jon.

--
--
== jon bird - software engineer
== <reply to address _may_ be invalid, real mail below>
== <reduce rsi, stop using the shift key>
== posted as: news 'at' onasticksoftware 'dot' co 'dot' uk

[Vadim Zeitlin]

On Sat, 25 Apr 2026 00:12:17 -0400 Kafrene Trading wrote:

KT> I’m a bit confused on the intended usage of wxSizer::Detach. The documentation (for the index variant) reads
KT>
KT> > Detach an item at position index from the sizer without destroying it.
KT>
KT> Which reads as though “it” refers to item, and item refers to the wxSizerItem. However, looking at the code for wxSizer::Detach, it is clear the item is, in fact, deleted.

Yes, this wording is indeed confusing/wrong. It should be changed to "without destroying the sizer or window contained in it" or something like this, I think.

KT> The window or sizer, if the item “held” one, is not destroyed, but the item itself is, which is surprising to me, since items can be more than just windows or sizers.

I also agree that it would make sense to have some wxSizer::DetachItem() that would return the detached item instead of deleting it, so that it could be passed to Add(wxSizerItem*) overload later.

KT> Ultimately this is something of an x-y problem: The actual goal I’d like to accomplish is being able to remove an item from the sizer, and then re-inserting it either immediately or at a later time, maybe hiding it for a while in the latter case.
KT>
KT> It’s not obvious how to accomplish this, afaics. I’d like to preserve any item attributes (size, border, align, etc.) and maintain abstraction over the underlying kind.
KT>
KT> I suppose I could check the kind and copy everything manually, but that feels less than ideal to have in application code.

Yes, indeed.

KT> Is there a better way to do this rather than copying the sizer item attributes, detaching, creating a new item with those attributes, then inserting?

I don't think so, unfortunately.

KT> If not, would a PR for something like this (“Detach”, though maybe by a different name given the different behavior, which accepts a sizer item and does the detach without deleting the item) make sense?

Yes, adding DetachItem() (or a function with a different name if you have better proposals for it — but not just Detach() because this would be confusing) would make sense and would provide a good solution to your problem.

Thanks!
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
https://www.tt-solutions.com/