Re: Unexpected wxSizer::Detach Behavior

--8323329-619054081-1777120116=:3987
Content-Type: TEXT/PLAIN; CHARSET=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: INLINE

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

KT> I=E2=80=99m a bit confused on the intended usage of wxSizer::Detach. Th=
e documentation (for the index variant) reads
KT>=20
KT> > Detach an item at position index from the sizer without destroying it=
.
KT>=20
KT> Which reads as though =E2=80=9Cit=E2=80=9D refers to item, and item ref=
ers to the wxSizerItem. However, looking at the code for wxSizer::Detach, i=
t is clear the item is, in fact, deleted.

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

KT> The window or sizer, if the item =E2=80=9Cheld=E2=80=9D one, is not des=
troyed, 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() t=
hat 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=E2=80=
=99d 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 i=
t for a while in the latter case.
KT>=20
KT> It=E2=80=99s not obvious how to accomplish this, afaics. I=E2=80=99d li=
ke to preserve any item attributes (size, border, align, etc.) and maintain=
 abstraction over the underlying kind.
KT>=20
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 att=
ributes, detaching, creating a new item with those attributes, then inserti=
ng?

 I don't think so, unfortunately.

KT> If not, would a PR for something like this (=E2=80=9CDetach=E2=80=9D, t=
hough 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 =E2=80=94 but not just Detach() because this would =
be confusing) would make sense and would provide a good solution to your pr=
oblem.

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

--8323329-619054081-1777120116=:3987
Content-Type: APPLICATION/PGP-SIGNATURE

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQx+vLQdOwioQqkxtoG6kHeT2wehgUCaeyzcwAKCRAG6kHeT2we
hhjUAJ9662/piWGh/fOVpgYzgK1YZm3xCQCgjDI0p9PqZ1brAhNXjzl9eI3ITRE=
=52X8
-----END PGP SIGNATURE-----

--8323329-619054081-1777120116=:3987--