Win32: modal dialog leaves a trail in the client area of parent/owner

Question

I'm writing a plug-in for an app; the plug-in is to display a modal dialog. It displays just fine, but when I move it, it leaves a trail on the screen, i.e. the window below doesn't redraw. Some parts of it do redraw (all standard Windows controls, e.g. toolbar or scrollbar), but the rest of the client area does not.

I'm using DialogBoxIndirectParam; the hWnd is the top window of the app, the template I construct on the fly and the dialog flags are WS_POPUP | WS_CAPTION | DS_MODALFRAME | DS_SETFONT | WS_SYSMENU, plus the function sets some flags itself, e.g. WS_CLIPSIBLINGS. The dialog class is standard (CS+DBLCLKS,CS_SAVEBITS) The dialog procedure is very basic, it only handles the WM_CLOSE message at the moment.

I tried Google but didn't manage find anything directly relevant. I tried to compare my dialog class with other dialogs of the same app and also checked the messages logs, but I didn't see any drastic differences.

Why doesn't the parent/owner redraw and how do I fix it?

Update. Here's the relevant calls.

Calling the dialog:

class Dialog(object):
    def run(self):
        t = cast(c_char_p(self.template()), LPCDLGTEMPLATE)
        p = GetActiveWindow()
        r = DialogBoxIndirectParamW(0, t, p, dialog_proc_2, py_object(self))

Window procedure:

def dialog_proc(window, message, wparam, lparam):
    if message == WM_CLOSE:
        EndDialog(window, IDCANCEL);
        return 1
    return 0

This is Python code :) it's embedded Python working via ctypes. The plug-in runs in the main thread; the host application makes a synchronous call, i.e it waits for the called function to return. self.template() returns DLGTEMPLATEEX data I prepare on the fly; I believe I do this correctly, because the dialog displays and when I check it with Spy all flags seems to be set (except that there's a few more). I don't use the instance handle, because I don't load anything from resources. I believe I correctly wrapped all functions and constants, but I can post the definitions too. GetActiveWindow (or GetForegroundWindow) returns the pointer to the app's main window; it's a MDI app and it repaints everything except the client area of a MDI window:

Screenshot of the problem showing the trail

Here I moved the window over all the visible windows (toolbars, buttons, etc.) and the only part that doesn't repaint is the client area of the MDI doc.

Post a small repro project that exhibits this behavior to a file sharing service. — Hans Passant
Your parents WM_PAINT or WM_ERASEBKGND handling is likely incorrect. Show us the code. — Erik
I'm not sure I can prepare a working snippet; it's a DLL that embeds Python, the code is in Python too and the WinAPI functions are called via ctypes :) The big idea is to have a scripted dialog constructor. But I can post all the API calls here, of course. I also don't have access to parent code; as I said, it's a plug-in. I have access to code of another plug-in that also shows a dialog, but it seems to be same, except that it restores parent's focus when closing the dialog. — Mikhail Edoshin

David Heffernan David Heffernan · Accepted Answer · 2011-02-20T18:14:24

You need the message queue to be pumped to make the paint cycle works. It seems that there is some pumping occurring (you say that some controls re-draw).

Since modal dialogs run their own message pump, I'm going to take a wild guess that the host for your plugin has some special treatment of messages, quite possibly erroneous, in its message pump and that your standard dialog box message pump does things differently.

I'm guessing and making large leaps of faith, but I suspect your host app's message loop isn't of the standard TranslateMessage / DispatchMessage form. If so then you are truly hosed.

Without more details it's really impossible to say anything with much certainty. As Hans says, a minimal reproduction would make the problem easy to solve.

Win32: modal dialog leaves a trail in the client area of parent/owner

1 Answers