Analysis of WM_CAPTURECHANGED usage in Wine to predict if an incoming correctedness patch will cause any side-effects.

The patch creates additional WM_CAPTURECHANGED messages in the case where a window losing focus is the same as the window gaining focus. This more correctly mimics Windows' behavior. Wine did not previously do this, causing a long-standing though isolated bug.

dlls/user.exe16/message.c:    case WM_CAPTURECHANGED:

OK. Code is simply specifying WM_CAPTURECHANGED to ensure it is ignored.

dlls/winemac.drv/window.c:            SendMessageW(previous, WM_CAPTURECHANGED, 0, (LPARAM)hwnd);

Appears to be in need of the same patch as I'm suggesting. Any idea why this code appears duplicated? Something about OS X having a different window server than *nix?

dlls/comctl32/tests/button.c:    { WM_CAPTURECHANGED, sent|wparam|defwinproc, 0 },

Should be fine. WM_CAPTURECHANGED is simply here as part of a test message sequence.

dlls/comctl32/tests/monthcal.c:    { WM_CAPTURECHANGED, sent|wparam|lparam|defwinproc, 0, 0},

Same as above.

dlls/comctl32/toolbar.c:	case WM_CAPTURECHANGED:

Probably fine? Appears to be a ToolbarProc translating window messages into toolbar-based equivalents.

dlls/comctl32/trackbar.c:    case WM_CAPTURECHANGED:

Same as above (for trackbars).

dlls/user32/button.c:    case WM_CAPTURECHANGED:
dlls/user32/button.c:        TRACE("WM_CAPTURECHANGED %p\n", hWnd);

Both lines part of the same button procedure. WM_CAPTURECHANGED causes get_button_state() to be called here and, if the button is pressed, causes the state to gain BUTTON_NSTATES.

Somebody who knows user32/button.c may want to comment.

dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|wparam|defwinproc, 0 },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|wparam|defwinproc, 0 },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|wparam|defwinproc, 0 },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|defwinproc },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|defwinproc },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|defwinproc },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|defwinproc|wparam|lparam, 0, 0 },
dlls/user32/tests/msg.c:	case WM_CAPTURECHANGED:
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|wparam|lparam, 0, WND_POPUP_ID }, /* popup */
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|defwinproc },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|defwinproc },
dlls/user32/tests/msg.c:    { WM_CAPTURECHANGED, sent|wparam|lparam|defwinproc, 0, 0 },
dlls/user32/tests/msg.c:    case WM_CAPTURECHANGED:

OK. All part of pre-defined message patterns with the exception of the two cases. user32 tests still pass with patch.

dlls/user32/tests/edit.c:static BOOL got_wm_capturechanged = FALSE;
dlls/user32/tests/edit.c:        case WM_CAPTURECHANGED:
dlls/user32/tests/edit.c:                got_wm_capturechanged = TRUE;
dlls/user32/tests/edit.c:    ok(got_wm_capturechanged, "main window capture did not change\n");

OK? Test continues to pass.

dlls/user32/tests/win.c:        case WM_CAPTURECHANGED:

OK? Test continues to pass.

dlls/user32/spy.c:    "WM_CAPTURECHANGED",

OK. Just a definition.

dlls/user32/input.c:            SendMessageW( previous, WM_CAPTURECHANGED, 0, (LPARAM)hwnd );

OK. This is what my original patch addressed.

include/winuser.rh:#define WM_CAPTURECHANGED      0x0215

OK. Just a definition.

programs/regedit/childwnd.c:    case WM_CAPTURECHANGED:

Unsure. Looks innocuous to me but somebody who knows regedit better could attest.

programs/taskmgr/graph.c:    case WM_CAPTURECHANGED:

OK. Simply filtering it out.

programs/taskmgr/graphctl.c:    case WM_CAPTURECHANGED:

Same as above.

tools/winapi/winapi_module_user.pm:    WM_CAPTURECHANGED => {

OK. Just a definition.