diff options
author | ashok <ashok> | 2016-05-12 04:50:10 (GMT) |
---|---|---|
committer | ashok <ashok> | 2016-05-12 04:50:10 (GMT) |
commit | 2f3688a7e8fa7418679daffc1e6127e5fec29879 (patch) | |
tree | cbc6333c2ef5b8f417d02a953a14ea5f4aea651d /win/tkWinDialog.c | |
parent | 24bc5ef7c2cec7c5f05169c1903fd481688960c1 (diff) | |
download | tk-2f3688a7e8fa7418679daffc1e6127e5fec29879.zip tk-2f3688a7e8fa7418679daffc1e6127e5fec29879.tar.gz tk-2f3688a7e8fa7418679daffc1e6127e5fec29879.tar.bz2 |
Bug [64261b50]. Spurious mouse events sent to underlying window when file dialog is closed.
Diffstat (limited to 'win/tkWinDialog.c')
-rw-r--r-- | win/tkWinDialog.c | 28 |
1 files changed, 16 insertions, 12 deletions
diff --git a/win/tkWinDialog.c b/win/tkWinDialog.c index d7db04c..1ee1e4a 100644 --- a/win/tkWinDialog.c +++ b/win/tkWinDialog.c @@ -674,19 +674,25 @@ static void LoadShellProcs() * processing functions are used to cope with keyboard navigation of * controls.) * - * Here is one solution. After returning, we poll the message queue for - * 1/4s looking for WM_LBUTTON up messages. If we see one it's consumed. - * If we get a WM_LBUTTONDOWN message, then we exit early, since the user - * must be doing something new. This fix only works for the current - * application, so the problem will still occur if the open dialog - * happens to be over another applications button. However this is a - * fairly rare occurrance. + * Here is one solution. After returning, we flush all mouse events + * for 1/4 second. In 8.6.5 and earlier, the code used to + * poll the message queue consuming WM_LBUTTONUP messages. + * On seeing a WM_LBUTTONDOWN message, it would exit early, since the user + * must be doing something new. However this early exit does not work + * on Vista and later because the Windows sends both BUTTONDOWN and + * BUTTONUP after the DBLCLICK instead of just BUTTONUP as on XP. + * Rather than try and figure out version specific sequences, we + * ignore all mouse events in that interval. + * + * This fix only works for the current application, so the problem will + * still occur if the open dialog happens to be over another applications + * button. However this is a fairly rare occurrance. * * Results: * None. * * Side effects: - * Consumes an unwanted BUTTON messages. + * Consumes unwanted mouse related messages. * *------------------------------------------------------------------------- */ @@ -698,10 +704,7 @@ EatSpuriousMessageBugFix(void) DWORD nTime = GetTickCount() + 250; while (GetTickCount() < nTime) { - if (PeekMessageA(&msg, 0, WM_LBUTTONDOWN, WM_LBUTTONDOWN, PM_NOREMOVE)){ - break; - } - PeekMessageA(&msg, 0, WM_LBUTTONUP, WM_LBUTTONUP, PM_REMOVE); + PeekMessageA(&msg, 0, WM_MOUSEFIRST, WM_MOUSELAST, PM_REMOVE); } } @@ -1424,6 +1427,7 @@ static int GetFileNameVista(Tcl_Interp *interp, OFNOpts *optsPtr, oldMode = Tcl_SetServiceMode(TCL_SERVICE_ALL); hr = fdlgIf->lpVtbl->Show(fdlgIf, hWnd); Tcl_SetServiceMode(oldMode); + EatSpuriousMessageBugFix(interp); /* * Ensure that hWnd is enabled, because it can happen that we have updated |