Dan Kegel dank@kegel.com wrote:
@@ -190,6 +190,8 @@ HOTKEY_Paint(HOTKEY_INFO *infoPtr, HDC hdc) HOTKEY_Refresh(infoPtr, hdc); else { PAINTSTRUCT ps;
- /* In some apps, the hotkey doesn't draw unless we invalidate it here */
- InvalidateRect(infoPtr->hwndSelf, NULL, FALSE);
It doesn't make sense to invalidate before painting in the paint handler.
On Mon, Jun 18, 2012 at 11:41 AM, Dmitry Timoshkov dmitry@baikal.ru wrote:
- /* In some apps, the hotkey doesn't draw unless we invalidate it here */
- InvalidateRect(infoPtr->hwndSelf, NULL, FALSE);
It doesn't make sense to invalidate before painting in the paint handler.
Looking at the +win log for the app in question, I see something interesting:
0009:Call window proc 0x5f401b81 (hwnd=0x10170,msg=WM_PAINT,wp=00000000,lp=00000000) trace:win:BeginPaint hdc = 0x1bc box = ((0,0)-(161,16)), fErase = 0 0009:Call window proc 0x7e2fd880 (hwnd=0x10170,msg=WM_PAINT,wp=00000000,lp=00000000) trace:win:BeginPaint hdc = 0x368 box = ((0,0)-(0,0)), fErase = 0
So the hotkey control is getting an empty update area because some other window procedure already called BeginPaint for this event.
I spoke with the developer, and he agreed this is an app bug. His source subclasses the hotkey control, and in the subclass, he had MyHotkeySubclass::OnPaint() { CPaintDC foo; if (...) { handle draw here; } else { call superclass windowproc; } } The fix for the app bug is probably to move the CPaintDC inside the if.
But why did this code work with native comctl32? Could this particular thinko be common enough that Microsoft implemented a workaround for it? It seems so, because when I use native comctl32, I see a similar InvalidateRect call.
So, that's why I think this change belongs in wine. That said, the app developer will probably fix his (very old) bug now that I've pointed it out. - Dan