http://bugs.winehq.org/show_bug.cgi?id=7404
P. Quist pq@quistnet.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pq@quistnet.nl
--- Comment #19 from P. Quist pq@quistnet.nl 2008-03-20 18:24:56 --- Well just a quick word, I've been trying to get the source of this damn bug for 2 days now, and I can't find it.
There's a couple of things that the minimize does right, and it's perfectly traceable in the code, but the following sequence seems to be created out of thin air: - WM_PAINT - WM_NCPAINT - WM_ERASEBKGND
When I tried to block wm_paints from begin getmessaged, it screwed up a lot of things, so if someone knows where it's coming from, be my guest to hint away. But I put traces and debug messages pretty much everywhere and it didn't get me any closer.
I did manage to prevent a false WM_CANCELMODE to be sent, which is sent in dlls/winex11.drv/event.c :: EVENT_FocusOut, and can be prevented by a simple if(style is Wm_minimize), but that's totally unrelated.
What I do think is that the WM_PAINT isn't really the source of this particular problem to be honest, and when someone finds out how to prevent the WM_PAINT sequence, we should be going around debugging the mfc42 and related calllings.
That's just my take on it anyway, I could be incredibly wrong.
I'm not continuing on this bug, as my vision is pretty blurred now.