Tab control & Z-Order и не только
Это случай из реальной жизни. Следующие из него советы вы можете видеть в 2 записях выше.
Предыстория
Я писал собственный TabControl "с нуля". Связано это было с тем, что стандартный TabControl не позволяет отрисовывать свои страницы, только элементы заголовка, а для программы нужно было перерисовать его целиком. TabControl был успешно нарисован, и пришла пора его вставлять на место старого стандартного. И вот тут-то появилась проблема: если сабж по таб-ордеру идет перед элементами, которые лежат "поверх" него, то эти элементы рисуются, но по ним нельзя кликнуть - все клики получает TabControl. Если же TabControl идет по таб-ордеру после элементов, то он их загораживает и их не видно. Задача не так тривиальна как может показаться на первый взгляд, особенно если нельзя менять исторически сложившийся таб-ордер. При этом стандартный виндовский TabControl ведет себя одинаково независимо от своего положения - не загораживает контролы и не задерживает клики.
Решение
1) Установить табконтролу (ну или что вы там рисуете) стиль WS_CLIPSIBLINGS. Это вырежет из области его перерисовки прямоугольники "загороженных" элементов управления, таким образом он не будет их загораживать "графически".
2) Обработать сообщение WM_NCHITTEST и для всех неинтересных областей (у TabControl это все кроме кнопок, переключающих страницы) вернуть HTTRANSPARENT, для остального - по усмотрению, например HTCLIENT. Это сделает ваш контрол прозрачным "физически", и он больше не будет задерживать клики мышью.
This is a real-life case. You can read advices following from it in two above records.
Story
I was writing a tab control of my own from a scratch. I needed that because standard tabcontrol doesn't allow to draw its pages, only header buttons, but i needed to draw entire control. When the control was drawn and i started to replace old controls with new ones, a problem came up. If my new tab was tab-ordered before other controls, i couldn't click those controls because tab received clicks. If it was ordered after them, they received clicks but were not drawn because tab obscured them. I also had to keep the original tab-ordering intact. Surprisingly, default tab control ignores those problems and works well regardless of its ordering.
Soltuion
1) Set WS_CLIPSIBLINGS style to your control. The regions of underlying controls (if any) will be extracted from its drawing area, so your control will not obscure underlying ones regardless of tab-order.
2) Handle WM_NCHITTEST in your control and return HTTRANSPARENT for all areas that you wish to pass clicks through, returning something like HTCLIENT for "solid" areas. With that, your control will pass all mouse events to underlying controls regardless of tab-order.
Предыстория
Я писал собственный TabControl "с нуля". Связано это было с тем, что стандартный TabControl не позволяет отрисовывать свои страницы, только элементы заголовка, а для программы нужно было перерисовать его целиком. TabControl был успешно нарисован, и пришла пора его вставлять на место старого стандартного. И вот тут-то появилась проблема: если сабж по таб-ордеру идет перед элементами, которые лежат "поверх" него, то эти элементы рисуются, но по ним нельзя кликнуть - все клики получает TabControl. Если же TabControl идет по таб-ордеру после элементов, то он их загораживает и их не видно. Задача не так тривиальна как может показаться на первый взгляд, особенно если нельзя менять исторически сложившийся таб-ордер. При этом стандартный виндовский TabControl ведет себя одинаково независимо от своего положения - не загораживает контролы и не задерживает клики.
Решение
1) Установить табконтролу (ну или что вы там рисуете) стиль WS_CLIPSIBLINGS. Это вырежет из области его перерисовки прямоугольники "загороженных" элементов управления, таким образом он не будет их загораживать "графически".
2) Обработать сообщение WM_NCHITTEST и для всех неинтересных областей (у TabControl это все кроме кнопок, переключающих страницы) вернуть HTTRANSPARENT, для остального - по усмотрению, например HTCLIENT. Это сделает ваш контрол прозрачным "физически", и он больше не будет задерживать клики мышью.
This is a real-life case. You can read advices following from it in two above records.
Story
I was writing a tab control of my own from a scratch. I needed that because standard tabcontrol doesn't allow to draw its pages, only header buttons, but i needed to draw entire control. When the control was drawn and i started to replace old controls with new ones, a problem came up. If my new tab was tab-ordered before other controls, i couldn't click those controls because tab received clicks. If it was ordered after them, they received clicks but were not drawn because tab obscured them. I also had to keep the original tab-ordering intact. Surprisingly, default tab control ignores those problems and works well regardless of its ordering.
Soltuion
1) Set WS_CLIPSIBLINGS style to your control. The regions of underlying controls (if any) will be extracted from its drawing area, so your control will not obscure underlying ones regardless of tab-order.
2) Handle WM_NCHITTEST in your control and return HTTRANSPARENT for all areas that you wish to pass clicks through, returning something like HTCLIENT for "solid" areas. With that, your control will pass all mouse events to underlying controls regardless of tab-order.