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

Have you checked out Magic the user interface library?  They have a tab control you can get the source code for.  Perhaps it might be easier to start with that as a base http://www.dotnetmagic.com/

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.

Two options that I have found:

1. Override the OnPaintBackground event and take out the call to the base event.
2. Override wndProc and trap the WMPaint and WMMystery events and do your drawing there.

Hope that helps!

I've created my own TabControl. I didn't inherite from original TabControl
and seems like it works not bad. I used Panel objects as a pages for the control.