Почему мой WinForms UserControl перестает запускать события Paint, когда BorderStyle = None?

Question

Я только что обнаружил проблему, когда один из моих UserControls загадочным образом прекратил запуск событий Paint.

Оказывается, для BorderStyle было случайно установлено значение None.Когда я установил его обратно в FixedSingle, события Paint снова начали срабатывать.

Меня это удивило - какая-то идея, почему это происходит?

edit TheUserControl основан на стороннем элементе управления (ASE ChartDirector) , и у нас была другая проблема с ним.Когда для BackColor установлено значение «Прозрачный», он будет запускать события рисования непрерывно !.Обходной путь в этом случае состоял в том, чтобы установить BackColor в ControlLightLight. (см. Этот вопрос для получения более подробной информации)

Может ли это быть ключом к проблеме BorderStyle?

Answer 1

Вот очень хороший блог пост , в котором очень подробно обсуждается причина этого.

Обновление: эта статья предназначена для WPF, однако в некоторых случаях WPF и Windows Forms касаются HWND, WParam, LParam.

Вот почему я думаю, что события рисования могут не обрабатываться (текст ниже такой, как на статье).

Операционная система должна очень быстро реагировать на движение мыши. Windows использует выделенный поток необработанных данных (RIT), запущенный в ядро, чтобы обрабатывать сигналы от оборудования мыши. RIT быстро просматривает иерархию HWND, чтобы увидеть, в каком окне находится мышь над. Поскольку система должна быть адаптивной, код приложения не вызывается. Для обычных окон RIT проверяет положение мыши против прямоугольника окна (или области, если она установлена). Но для Многослойные окна, RIT выглядит в растровом изображении, которое определяет содержание для окна и проверяет эффективную прозрачность при этом местоположение (которое может зависеть от настройки постоянной непрозрачности, настройка цветового ключа или альфа-канал на пиксель). Если пиксель 100% прозрачность, RIT пропускает окно и продолжает смотреть. Когда окно было установлено, флаг перемещения мыши установлен на поток, который владеет окном. Это приведет к тому, что поток получит WM_MOUSEMOVE сообщение в следующий раз, когда он вызывает GetMessage (), и нет других сообщения с более высоким приоритетом.

Хотя это особенно относится к сообщениям, поступающим от аппаратных сигналов мыши, я думаю, что нечто подобное может произойти и с другими событиями.

Вот что я бы сделал,

Внутри класса Form выполняется следующий код для просмотра обрабатываемых сообщений.

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

Я искал, но не мог получить больше информации.