Bug in Lister window?

[zsgm02]

Gentlemen,

There seems to be a problem with Lister window's WM_PAINT handling. My plugin window is a child of this window, and it's background color is completely omitted, at least it seems to be the case.

Here's a screenshot demonstrating the buggy display:

http://hetimetal.atw.hu/buggy_display.png

Here's a screenshot of the correct display (now my Lister dialog is hosted in a standard, very basic window):

http://hetimetal.atw.hu/correct_display.png

Anyone faced this problem before?

Thanks,
Zoltan

[ghisler(Author)]

Sorry, I can't help you directly, only give you some ideas what you could do:
In your window class, you can set a background brush. You may also try to set it to 0 to get background draw messages.

[zsgm02]

Thanks for the hint.

I already tried it, didn't help unfortunately (the message is WM_DLGCONTROLxxx or smth like that).
Moreover, the dummy Lister window (my tester app) wouldn't display my plugin dialog correctly if it were a problem with that. I suspect that (even though I don't have code) Lister has its own WM_PAINT handler which overrides any Brushes coming from child controls/dialogs.

[zsgm02]

Update:

Accidentally it turned out that the bug occurs only if at least 1 scrollbar is created for the parent Lister window. The bug also occurs if the Lister is configured for "immediate" creation of the Lister plugin child window by setting "Load bitmaps as graphics at startup".

I'm investigating further - if anyone has idea what's going on behind the scenes here, I would highly appreciate a comment.

Thanks,
Zoltan

[zsgm02]

Got stuck again. I can switch off scrollbars easily (and switch them back on whenever my plugin quits), which solves the problem of bad display in case the user explicitly has to switch to my plugin (via "Options"/"Image/Multimedia").

But still, if the default Lister child is not created beforehand, the white-background stays, and the UI looks awful.

[zsgm02]

It seems that Lister doesn't send WM_ERASEBKGND to the embedded plugin dialog.

I was able to eliminate the problem by handling WM_PAINT like this:

(in the DlgProc of my plugin dialog window)
...
case WM_PAINT:
{
HDC hDC = GetDC(hwnd);
DefDlgProc(hwnd, WM_ERASEBKGND, (WPARAM)hDC, 0);
ReleaseDC(hwnd, hDC);
}
break;