3 ms·

The dialog editor is a good example of the damage that was done with the VS.NET transition. When they rewrote it to use the WinForms-based UI, they introduced a

The dialog editor is a good example of the damage that was done with the VS.NET transition. When they rewrote it to use the WinForms-based UI, they introduced a fundamental bug: the Z-order for picking was reversed so that clicking on a stack of controls selected the one on the bottom. Very annoying for controls like group controls intended to be stacked below other controls. Bug filed, WONTFIX'd, and it's still broken to this day.

zerr 1y ago
Afaik Win32 API explicitly states that overlapping sibling windows/controls is not supported.
- ack_complete 1y ago
  No, 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 ago
    Right! It is wxWidgets that doesn't support overlapping siblings due to other back-ends (besides Win32) lacking support.

zerr 1y ago

Afaik Win32 API explicitly states that overlapping sibling windows/controls is not supported.

ack_complete 1y ago
No, 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 ago
  Right! It is wxWidgets that doesn't support overlapping siblings due to other back-ends (besides Win32) lacking support.