Прерывает ли Win10 обработку WM_PAINT новыми сообщениями WM_PAINT?

Question

Файл трассировки стека ошибок времени выполнения показывает, что оконная процедура вызывается дважды с сообщениями WM_PAINT. Окно было в середине перекрашивания из-за первого сообщения WM_PAINT (после BeginPaint, но до EndPaint), когда внезапно снова была вызвана оконная процедура для обработки нового сообщения WM_PAINT. По-видимому, это произошло после звонка SetBkColor или SelectObject.

Я понимаю, что это могло бы произойти, если бы наше приложение вызывало UpdateWindow (или использовало SendMessage для отправки WM_PAINT себе), но я не верь, что это когда-нибудь случится Более того, UpdateWindow не может использоваться, если область обновления пуста, что должно иметь место, поскольку BeginPaint проверяет область обновления.

Об этой проблеме сообщили нам два клиента, оба работающие под управлением Windows 10, но в нашем долговременном стабильном приложении такого никогда не было. Интересно, возможно ли, что Windows 10 (или какое-то временное автоматическое обновление Windows 10, возможно, позже будет исправлено), может начать с SendMessage лишних WM_PAINT сообщений?!? Даже если бы была какая-то веская причина отправлять их, а не публиковать, кажется неприемлемым принудительно возвращать рисование, когда BeginPaint активен.

Для каждого запроса вот псевдокод для трассировки стека:
RTS: необработанное исключение № 3: неверное местоположение
BW линия 3056 - RepaintChars
BW line 3071 - RepaintText
BW line 3242 - Перекраска (вызывается после BeginPaint до EndPaint)
ОСНОВНАЯ строка 85 - WindowProcedure (обрабатывает WM_PAINT здесь)
Не удается распознать модуль
Не удается распознать модуль
Не удается распознать модуль
BW линия 3056 - RepaintChars
BW линия 3071 - RepaintText
BW линия 2976 - RepaintAround
BW линия 3253 - перекраска (вызывается после BeginPaint до EndPaint)
ОСНОВНАЯ строка 85 - WindowProcedure (обрабатывает WM_PAINT здесь)
MAIN lin 145 - основной

Независимо от возможной несвязанной ошибки времени выполнения "неверное местоположение" в верхней части, я пытаюсь лучше понять здесь любопытные повторяющиеся сообщения WM_PAINT. Возможно, верхняя часть трассы стека является иллюзорным повторением нижней половины, но я так не думаю из-за небольших различий (например, отсутствие RepaintAround в верхней половине) и того, как каждое местоположение указывает на значимые линии, которые представляют согласованную картину .

Answer 1

Основываясь на комментариях, я теперь понимаю, что мой обработчик WM_PAINT не может быть прерван как внешне, так и внутренне вызовами SendMessage / GetMessage / PeekMessage, поэтому трассировка моего стека должна быть неправильной. Я предполагаю, что более короткий WM_PAINT след стека, возможно, был положен поверх более раннего более длинного WM_PAINT следа стека, формируя очевидно последовательную историю, которая ввела меня в заблуждение, что реентрант WM_PAINT сообщений происходило.

По-прежнему представляется возможным, что небольшое изменение по сравнению с некоторым обновлением Win10 могло вызвать эту ошибку во время выполнения, поскольку это произошло в надежной утилите просмотра текста, которая почти не изменилась за десятилетие. Моя трассировка стека указала на строку кода, которую можно было бы сделать более устойчивой к плохим данным, так что, надеюсь, это решено. Я ценю сообщество Stack Overflow, которое помогает мне в этом разобраться!