User drawn tab control in Win32 and XP
-
Using the vertical tab control style TCS_VERTICAL in themed XP is not possible, because Windows draws the tab horizontal instead of vertical. I have written code (in Win32) to draw the tabs vertical. The TCS_OWNERDRAWFIXED flag should prevent Windows from updating the tab. However, Windows still paints the tab background. Only the interior (text and icon) is not painted. To my code it means that one or more of the tabs are drawn empty, because Windows painting is done after my code is executed. Moreover, in a single line tab control with tabs extending the client window, Windows adds a spin control for scrolling. It seems to be updated elsewhere than WM_PAINT, because my code can get it disappear. Does anyone know how to control the way Windows is drawing the tab control? Best regards
Anton112
-
Thanks for your answer. I cannot argue that I can't use anything from it. But it still doesn't answer the main part of my question: how do I prevent Windows from painting the tab control background. I cannot use the sample directly because I don't have MFC (that's why I'm using Win32). Thanks.
Anton112
-
Thanks for your answer. I cannot argue that I can't use anything from it. But it still doesn't answer the main part of my question: how do I prevent Windows from painting the tab control background. I cannot use the sample directly because I don't have MFC (that's why I'm using Win32). Thanks.
Anton112
Did you try handling WM_ERASEBKGND[^]?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Life: great graphics, but the gameplay sux. <
-
Did you try handling WM_ERASEBKGND[^]?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Life: great graphics, but the gameplay sux. <
-
I'm out of ideas right now, sadly afaik in many controls the WM_PAINT message and such sort does not get always invoked when drawing occurs, instead probably the drawing code gets called directly by who knows what event handlers. I have seen this happening a few times. Of course i could be wrong... Anyways, try adding the WS_EX_TRANSPARENT style, no idea if it changes anything or even if it does not make things worse, it's just a hinch.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Life: great graphics, but the gameplay sux. <
-
Using the vertical tab control style TCS_VERTICAL in themed XP is not possible, because Windows draws the tab horizontal instead of vertical. I have written code (in Win32) to draw the tabs vertical. The TCS_OWNERDRAWFIXED flag should prevent Windows from updating the tab. However, Windows still paints the tab background. Only the interior (text and icon) is not painted. To my code it means that one or more of the tabs are drawn empty, because Windows painting is done after my code is executed. Moreover, in a single line tab control with tabs extending the client window, Windows adds a spin control for scrolling. It seems to be updated elsewhere than WM_PAINT, because my code can get it disappear. Does anyone know how to control the way Windows is drawing the tab control? Best regards
Anton112
-
Are you handling WM_DRAWITEM[^]? Best Wishes, -David Delaune
[Message Deleted]
-
Are you handling WM_DRAWITEM[^]? Best Wishes, -David Delaune
Hi David, and thanks for your interest. I have analysed my problem a bit more. WM_DRAWITEM is not sent at all. WM_ERASEBKGND is sent only upon repaint of the application (focus changed, window rezise etc.). If I add
return 0;to WM_PAINT, Windows stops updating the tabs, but the application is not updated either. By adding a flag to control WM_PAINT when the mouse is within the tab area (WM_MOUSEMOVE and WM_MOUSELEAVE) I can override Windows update, but only as long as the mouse is within the tab area. Do you have other ideas to which events I could respond? Kind regardsAnton112
-
[Message Deleted]
-
I'm out of ideas right now, sadly afaik in many controls the WM_PAINT message and such sort does not get always invoked when drawing occurs, instead probably the drawing code gets called directly by who knows what event handlers. I have seen this happening a few times. Of course i could be wrong... Anyways, try adding the WS_EX_TRANSPARENT style, no idea if it changes anything or even if it does not make things worse, it's just a hinch.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Life: great graphics, but the gameplay sux. <
-
Hi David, and thanks for your interest. I have analysed my problem a bit more. WM_DRAWITEM is not sent at all. WM_ERASEBKGND is sent only upon repaint of the application (focus changed, window rezise etc.). If I add
return 0;to WM_PAINT, Windows stops updating the tabs, but the application is not updated either. By adding a flag to control WM_PAINT when the mouse is within the tab area (WM_MOUSEMOVE and WM_MOUSELEAVE) I can override Windows update, but only as long as the mouse is within the tab area. Do you have other ideas to which events I could respond? Kind regardsAnton112
Hi Anton, There may be some useful information on the link provided below. Looks like the Tab control will require some ugly hacks to be fully customized. Hacking the Overall Background Color of a Windows Tab Control[^] I looked at a customized tab control I wrote a few years back and it looks like I was doing something similar. I was essentially drawing on top of what was already drawn! :-O Best Wishes, -David Delaune
-
Hi Anton, There may be some useful information on the link provided below. Looks like the Tab control will require some ugly hacks to be fully customized. Hacking the Overall Background Color of a Windows Tab Control[^] I looked at a customized tab control I wrote a few years back and it looks like I was doing something similar. I was essentially drawing on top of what was already drawn! :-O Best Wishes, -David Delaune
Hi David, I have to realize that it is too long time ago I wrote code for Windows last. First, I used
GetDC/ReleaseDCto get the DC for WM_PAINT where (I suppose) it should have beenBeginPaint/EndPaint. Second, I used the hWnd entered through theWndProccall for one of the functions and the locally stored m_hWnd for the other. I.e.GetDC(hWnd) ReleaseDC(m_hWnd). I don't hnow if it causes any trouble, but it is not very nice. Anyway, now I can prevent Windows from drawing the tabs, and the spin control is controlled by Windows (except in the vertical alignment: they are painted but not handled :mad:). The remaining problem is that I have to draw the whole tab background by myself. But I expect it to be a relatively small problem. Best regards AntonAnton112