[Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

wine-bugs at winehq.org wine-bugs at winehq.org
Tue Jul 22 16:55:56 CDT 2008


--- Comment #5 from Anastasius Focht <focht at gmx.net>  2008-07-22 16:55:29 ---
Created an attachment (id=14991)
 --> (http://bugs.winehq.org/attachment.cgi?id=14991)
Recorded call sequences from window proc (expected behaviour)


there seem to be at least two issues involved here.
It's a pain to debug this large app with all its unmanaged and managed code so
I sticked with investigating windbg behaviour in hope that's the same issue as
VS.NET 2005

Basically the message sequence for the affected window goes like this (5 calls
of that winproc):

(#1) WM_NCACTIVATE (active = TRUE)
(#4) WM_NCACTIVATE (active = FALSE)

After that sequence, the window refresh is finished.

The info for the affected window (opened via toolbar):

--- snip ---
Title="Scratch Pad - WinDbg:6.9.0003.113 X86"
ExtStyle=00000100 WS_EX_WINDOWEDGE
--- snip ---

Parent (top level):

--- snip ---
Title="WinDbg:6.9.0003.113 X86"
--- snip ---

I made note of each user32 call within the app window proc to keep things

After comparing both sequences, I noticed the following problem:

hRegionClip = NULL;

The call to user32.GetDCEx( hWndScratchWindow, hRegionClip, Flags) returned
NULL on Windows XP while Wine returned a valid DC.

After further investigation with google it seems this is some sort of
undocumented behaviour, see:

--- quote ---
As a side note, a poster on the forum recently helped me track down an
irritating bug in VirtualDub's draggable video frames that was causing some
instability on Win9x platforms.
It happened because of a code fragment that I adapted from the MSDN Library
documentation for WM_NCPAINT that supposedly helps you draw custom window
Well, the code fragment as given doesn't work, because it lacks an essential
GetDCEx() simply returns NULL and leaves the error code as NO_ERROR.
You need to add 0x10000, called "an undocumented flag which can magically make
GetDCEx call succeed" in Feng Yuan's GDI book, or DCX_USESTYLE by WINE, for the
function to actually return a usable DC.
It turns out that there is an even worse problem with the code as given because
it causes window regions to be doubly freed!
On Win9x, this results in an occasional crash in 16-bit GDI. (This particular
problem with the WM_NCPAINT example is also colorfully documented in comments
in the WINE source code.) After I fixed this issue, the poster's problem went
away. So if you are using a Win9x platform, expect some stability improvements
in edit mode in 1.6.4.
--- quote ---

I patched dlls/user32/painting.c:GetDCEx for testing purposes but it didn't
solve the endless looping problem.

The call sequences within that app window proc where GetDCEx was involved were
more matching, showing slight improvement over previous situation.
It seems the app directly checked for GetDCEx() returning NULL and took that
into account (expecting such result).
It remains mysterious why a Micro$oft app actually made this call with hard
coded flags when it's expected to return NULL?
Maybe the people there don't talk to each other/suffer from their own MSDN hell
Maybe some Windows versions show different behaviour?
This has to be added to conformance test ...


Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.

More information about the wine-bugs mailing list