I have overridden a lot of the windows controls to try and augment then with a more Windows XP look and feel or just to make the application more visually appealing.  This means I have to override a lot of the OnPaint and OnPaintBackground methods in my inherited controls / forms.  The problems is that a lot of times these aren't even called, especially OnPaintBackground.  Typically all I even want to do is just put a gradient background on a control like a datagrid or something, but instead of just being able to override OnPaintBackground I need to set the base class BackColor to transparent and override OnPaint by painting a background then calling the base class's OnPaint.  It would seem like the presence of the OnPaintBackground method in the object model indicates that it is what should be used when drawing the background of a control.  Why isn't it?  I guess what I just want to see is a richer control object model with meaningful methods to override and maybe some documentation indicating what methods are not used by the control (the OnPaintBackground on the datagrid does happen to be documented, but not the OnPaint of a TreeView and I'm sure others aren't either)

Paul Tyng

I think the problem with some of the controls in the Framework is that they simply wrap the common controls library.  Because the drawing of these controls takes place in native code, they do not quite behave like a normal, managed code control would.  Among the behaviors that are screwed up are, as you noticed, OnPaint and OnPaintBackground, as well as many messages not showing up in WndProc overrides.  

Only solution to this is to find some 100% managed code Controls to replace the Framework controls.  Occasionally I look for some, but havn't found any I liked yet.

Have a nice day,
Robert W. Grubbs