Owner-Drawn ToolStripDropDownButton

1.9k views Asked by At

I'm writing some custom behavior for a ToolStripDropDown control. I'd also like to modify the ToolStripDropDownButton itself to display a colored shape.

I see that I can handle the Paint event and draw whatever I like. However, is there any way to have the button paint the default background before I paint the shape? It would be hard to get the background exactly right, especially with future versions of .NET and Windows.

In plain ol' Windows, I could invoke the default proc handler before or after my paint code. I'm not seeing any way to accomplish that in .NET. Or perhaps there's a way to tell the button to paint only the background?

1

There are 1 answers

6
Cody Gray - on strike On BEST ANSWER

When you handle the Paint event (as opposed to overriding the OnPaint method in a derived class) the base class (default proc handler) is already getting called. Everything gets drawn as normal, and then you're essentially drawing on top of that in the Paint event. You can see that clearly here:

     Lime rectangle drawn over part of the drop-down button, clearly showing the default contents underneath

The trick is making sure that you leave enough of the control's clipping rectangle exposed to show the part you want. The e.ClipRectangle property retrieves the entire button's client area, so if you just
fill that with a color swatch, you're going to cover up the drop-down arrow and default background, too. The above demonstration was created using the following ugly sample code:

private void ToolStripDropDownButton1_Paint(object sender, PaintEventArgs e)
{
    e.Graphics.FillRectangle(Brushes.Chartreuse,
                             e.ClipRectangle.X + 3, e.ClipRectangle.Y + 3,
                             e.ClipRectangle.Width - 12,
                             e.ClipRectangle.Height - 12);
}

Other than that, I don't think there's a way to customize what exactly gets drawn by the base class. Owner-drawing (at least in WinForms) tends to be an all-or-nothing affair. You get complete control,
but it comes at the price of having to implement everything yourself.


Of course, in case you haven't already noticed, the ToolStrip control already doesn't look like a native Windows control. And even worse, it is always going to look exactly the same as it does now,
even in future versions of Windows that completely overhaul the UI. (The MenuStrip is plagued by
this same phenomenon, and the difference is very visible in Windows Vista/7 where the standard API menus have changed dramatically). The reason is that both controls are drawn entirely in C# code written in their WinForms implementations. Personally, I think it looks ridiculously cheesy, and wouldn't use it in one of my applications on a bet.

You can assign a custom renderer that uses the UxTheme API to draw the buttons, which will get much closer to approximating the look of the native menus and toolbars. A pretty thorough sample is available here. I've written something very similar for the WinForms development that I've done requiring the additional features of the ToolStrip class (such as embedding combo boxes) not offered by the
old-school MainMenu and ToolBar controls that simply wrap their Windows API equivalents. By choosing to do things this way, you do have more control over exactly what parts of the base class renderer you wish to call, as you've written the code explicitly yourself. Highly recommended if you're
the type that cares at all about UI, native feel, or user experience.