Why does my WinForms UserControl stop firing Paint events when BorderStyle = None?

I've just tracked down a problem, where one one of my UserControls mysteriously stopped firing Paint events.

Turns out the BorderStyle had been accidently set to None. When I set it back to FixedSingle, the Paint events started firing again.

This surprised the heck out of me - any idea why this is happening?

edit The UserControl is based on a 3rd party control (ASE ChartDirector), and we had another problem with it. When it's BackColor was set to Transparent, it would fire Paint even开发者_如何学运维ts continuously!. The workaround in that case was to set BackColor to ControlLightLight. (see this question for more details)

Could that also be a clue to the BorderStyle problem?

---

Here is a very nice blog post discussing in very detail the reason for that.

Update: This article is for WPF however, both WPF and Windows Forms touch HWND, WParam, LParam at some point.

Here is why I think that the paint events might not get processed (Text below is as it appears on the article).

The operating system must respond very quickly to mouse movement. Windows uses a dedicated Raw Input Thread (RIT), running in the kernel, to handle the signals from the mouse hardware. The RIT quickly scans over the HWND hierarchy to see which window the mouse is over. Because the system must be responsive, no application code is invoked. For normal windows, the RIT checks the mouse position against the window's rectangle (or region, if one is set). But for layered windows, the RIT looks in the bitmap that specifies the content for the window and checks the effective transparency at that location (which can be affected by the constant opacity setting, the color key setting, or the per-pixel alpha channel). If the pixel is 100% transparent, the RIT skips the window and keeps looking. Once a window has been located, the mouse move flag is set on the thread that owns the window. This will cause the thread to receive a WM_MOUSEMOVE message the next time it calls GetMessage() and there are no other higher-priority messages.

While this is particularly for messages coming from mouse hardware signals, I though that something similar could happen with other events too.

Here is what I would do,

Inside the Form class have the following code execute in order to watch the messages that are processed.

    protected override void WndProc(ref Message m)
    {
        Trace.WriteLine(m.Msg + ":" + m);
        base.WndProc(ref m);
    }

I searched but could not get more information around.