Re: comctl32/toolbar: Potential fix for button redraw in TBSTYLE_FLAT toolbars
On December 11, 2003 04:32 pm, Andrew de Quincey wrote:
I have concluded that the WM_ERASEBKGND is sent from within WM_PAINT when the toolbar detects that the mouse has moved off a button and wants to de-highlight it.
Well, it probably does a InvalidateRect() call. You can try an ugly InvaldateRect(hwnd, 0, TRUE); but this will probably result in flicker. For added bonus, figure out the button's rect, and pass it in: /* figure out stuff in rect */ InvalidateRect(hwnd, &rect, TRUE); BTW, what are the parameters of WM_ERASEBKGND? -- Dimi.
On Thursday 11 December 2003 22:45, Dimitrie O. Paun wrote:
On December 11, 2003 04:32 pm, Andrew de Quincey wrote:
I have concluded that the WM_ERASEBKGND is sent from within WM_PAINT when the toolbar detects that the mouse has moved off a button and wants to de-highlight it.
Well, it probably does a InvalidateRect() call. You can try an ugly InvaldateRect(hwnd, 0, TRUE); but this will probably result in flicker. For added bonus, figure out the button's rect, and pass it in:
/* figure out stuff in rect */ InvalidateRect(hwnd, &rect, TRUE);
Actually, that code is almost already in there... it does call InvalidateRect() already, but passes FALSE because TOOLBAR_HasText() returns false. This happens in the TOOLBAR_MouseMove() function. Originally, I had decided that this wasn't what windows does because in spyxx, the WM_ERASEBKGND occurs AFTER the WM_PAINT. However, I now see I have misread MSDN: The call to BeginPaint() inside the WM_PAINT issues the WM_ERASEBKGND because bErase was TRUE, so it would obviously occur after the WM_PAINT. This sounds much nicer.
BTW, what are the parameters of WM_ERASEBKGND?
wParam == device context handle lParam == unused
On Thursday 11 December 2003 23:00, Andrew de Quincey wrote:
On Thursday 11 December 2003 22:45, Dimitrie O. Paun wrote:
On December 11, 2003 04:32 pm, Andrew de Quincey wrote:
I have concluded that the WM_ERASEBKGND is sent from within WM_PAINT when the toolbar detects that the mouse has moved off a button and wants to de-highlight it.
Well, it probably does a InvalidateRect() call. You can try an ugly InvaldateRect(hwnd, 0, TRUE); but this will probably result in flicker. For added bonus, figure out the button's rect, and pass it in:
/* figure out stuff in rect */ InvalidateRect(hwnd, &rect, TRUE);
Actually, that code is almost already in there... it does call InvalidateRect() already, but passes FALSE because TOOLBAR_HasText() returns false. This happens in the TOOLBAR_MouseMove() function.
Originally, I had decided that this wasn't what windows does because in spyxx, the WM_ERASEBKGND occurs AFTER the WM_PAINT.
However, I now see I have misread MSDN: The call to BeginPaint() inside the WM_PAINT issues the WM_ERASEBKGND because bErase was TRUE, so it would obviously occur after the WM_PAINT. This sounds much nicer.
On second thoughts, that method would need multiple changes in the file to ensure the correct value was passed to InvalidateRect(). Whereas the method I proposed just needs three lines. Which do people prefer?
On December 11, 2003 06:07 pm, Andrew de Quincey wrote:
On second thoughts, that method would need multiple changes in the file to ensure the correct value was passed to InvalidateRect(). Whereas the method I proposed just needs three lines.
Calling InvalidateRect() is the right thing to do, we can't just send WM_ERASEBKGND messages like so... -- Dimi.
On Thursday 11 December 2003 23:30, Dimitrie O. Paun wrote:
On December 11, 2003 06:07 pm, Andrew de Quincey wrote:
On second thoughts, that method would need multiple changes in the file to ensure the correct value was passed to InvalidateRect(). Whereas the method I proposed just needs three lines.
Calling InvalidateRect() is the right thing to do, we can't just send WM_ERASEBKGND messages like so...
Cool. I shall make it do that then.
participants (2)
-
Andrew de Quincey -
Dimitrie O. Paun