tags:

views:

33

answers:

2

Hi All,

Is it possible to create a form with controls allowed to draw outside their (client) area?

In WPF, this is not only possible but it's even the default: ClipBounds = false;.

How can I do the same in WinForms?

TIA,

+1  A: 

This isn't really possible (easily) in Windows Forms. Windows Forms creates a separate window (HWND) per control. HWND's are restricted to a specific region for drawing, and when you nest them, they automatically get clipped to their parent HWND.

WPF works around this by only using one HWND for a Window, so when you have "controls", they're just rendered by WPF, not by actual OS window handles.

The best workaround is to make a larger "parent" window (potentially transparent) and put your controls into that, so that the clipping doesn't happen. It's tricky to get right.

Reed Copsey
By intercepting the Paint messages. especially the WM_NCPAINT, can't you accomplish painting outside of the control boundaries or will it by clippled too?
jmayor
The WM_NCPAINT is for the non-client areas of the window, such as the title bar, etc. It has a very different effect than the WPF ClipBounds effects. Mimicking WPF's behavior in Windows Forms basically means doing all of your own painting, and completely abandoning the Windows Forms control model. At that point, you're better off just hosting WPF in an ElementHost Control.
Reed Copsey
+1  A: 

Well, you can. You'll need to obtain a Graphics context for the parent form or container. It is easy to get one with Control.CreateGraphics(). But it won't work well, especially when you run on XP or with Aero disabled. The parent will draw its background without regard for your pixels, wiping them out when it is told to repaint itself. Very visibly if you move another window across your form.

You could work around this by letting the parent notify the control that it did so, passing the e.Graphics object in the OnPaintBackground and OnPaint overrides to the control. Not pretty.

Having a control draw itself on the background of a container was common back in the ActiveX control days. They were known as "windowless controls", common in VB6 for example. Back then, that was necessary to keep programs performant. It made a bit of a comeback in .NET 2.0 with the ToolStripItem class. And WPF of course. Common in browsers too. Writing such controls is however not easy, it takes a lot of code to replace the functionality provided by a window and the Control class. ToolStripXxx is notable for the large number of bugz in its code.

Hans Passant
Thanks for your thoughts. They are much appreciated. It was hard to decide whether to accept yours or Reed's. I eventually picked Reed's for the explanation of the difference with WPF.
Serge - appTranslator