Owner-drawn TabControl...
Hi, Coders
I have very strange problem!
I am deriving my own class, inherited from TabControl.
I need to make my own painting, so I wrote that:
SetStyle(ControlStyles.AllPaintingInWmPaint, true);
SetStyle(ControlStyles.UserPaint, true);
SetStyle(ControlStyles.DoubleBuffer, true);
Then proccessing the OnPaint method worked just fine, but when I decided to handle the scrolling of the tab pages I found out that I CAN'T get rid of the two scroll buttons windows draws on the tab control. I overrode almost every possible virtual method and put "Invalidate" in it, but the scroll buttons still appear:(
Any idea of how scrolling the pages on my own, without the help of windows?
The code you've shown here will provide support for double-buffering, which you may or may not need. Seems to me that when you inherit from an existing control, and you call the OnPaint method of the base class, you're going to get the entirety of the control painted by Windows and the CLR. Your options are to accept that, or do ALL the drawing yourself (that is, draw every single line and pixel of the control on your own).
If you don't like the way Windows draws the control, don't call the base class' OnPaint method. But you'll need to be prepared to draw the entire control yourself.
Thanks for your reply, Ken
But it didn't helped me:(
The only use of DoubleBuffering is to reduce flicker when painting...
You call the base.OnPaint in order to make sure that the control will receive the event.
Setting ControlStyles.UserPaint to true tells the system that you will handle the drawing yourself. I am doing this - drawing the entire control and the tab pages within it. But may be scrolling of the tab pages is represented through some event of higher priority, I don't know...
Or I should try overriding the WndProc...
Any ideas of when scrolling the tab pages what event occurs and how can I handle that event?
Cheers,
Gogou
The problem is that the TabControl (which wraps the Win32\COMCTL tab control) creates an "up-down" control for the scroll buttons. The up-down controls paint themselves, so handling the paint for the TabControl doesn't keep the up-down controls from painting.
You might be able to do some really hard-core Win32 processing. You would have to get the handle of the child control with the class name of msctls_updown32, then perform standard Win32 subclassing (using GetWindowLong/SetWindowLong). Not for the faint of heart.
-Mark
Thanks for your help, Mark
I supposed there is something like that - as this updown control is not affected by any message through wndproc
I wondered why every one who decides to implement his own TabControl inherits from user control :))
I wanted to have all the other cool stuff TabControl implements and also to have IDE look:)
Cheers,
Gogou
Just a thought: Study the docs for the following TabControl properties, to see if these can help you achieve what you want with less pain...
- Appearance
- DrawMode
- Multiline <-- Might force the arrow buttons to go away? Just a guess.
- SizeMode
Iain Heath,
WinForms team.
