summaryrefslogtreecommitdiffstats
path: root/win
diff options
context:
space:
mode:
authorashok <ashok>2016-05-12 04:50:10 (GMT)
committerashok <ashok>2016-05-12 04:50:10 (GMT)
commit0c4ee478b9b69358c5020ab5378d017e99d17292 (patch)
treecbc6333c2ef5b8f417d02a953a14ea5f4aea651d /win
parent891d17025fdd69570f9a14ea3d7333b0ca53a87c (diff)
downloadtk-0c4ee478b9b69358c5020ab5378d017e99d17292.zip
tk-0c4ee478b9b69358c5020ab5378d017e99d17292.tar.gz
tk-0c4ee478b9b69358c5020ab5378d017e99d17292.tar.bz2
Bug [64261b50]. Spurious mouse events sent to underlying window when file dialog is closed.
Diffstat (limited to 'win')
-rw-r--r--win/tkWinDialog.c28
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