5 ms·
Afaik Win32 API explicitly states that overlapping sibling windows/controls is not supported.
by zerr 1y ago
Afaik Win32 API explicitly states that overlapping sibling windows/controls is not supported.
- ack_complete 1y agoNo, overlapping sibling controls is absolutely supported in Win32. It has a defined Z-order for child controls along with functions to manage it: > The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows. https://learn.microsoft.com/en-us/windows/win32/winmsg/window-features#z-order https://learn.microsoft.com/en-us/windows/win32/winmsg/windo... The WS_CLIPSIBLINGS window style is also explicitly for controlling cross-clipping of child windows during painting: > Clips child windows relative to each other; that is, when a particular child window receives a WM_PAINT message, the WS_CLIPSIBLINGS style clips all other overlapping child windows out of the region of the child window to be updated. https://learn.microsoft.com/en-us/windows/win32/winmsg/window-styles https://learn.microsoft.com/en-us/windows/win32/winmsg/windo... Furthermore, group boxes and tab controls require overlapping child windows, because they are designed for the controls that visually appear within them to be sibling controls that are raised in Z-order. This is why the dialog editor's current behavior is broken, because the editor's picking behavior is opposite the drawing behavior and USER32's hit test order.
- zerr 1y agoRight! It is wxWidgets that doesn't support overlapping siblings due to other back-ends (besides Win32) lacking support.