* win/tkWinDialog.c (EatSpuriousMessageBugFix): Fix a problem with

	double clicks in file dialogs falling through to the window
	underneath in win32. [Patch #611615]

1 files changed, 50 insertions, 2 deletions

diff --git a/win/tkWinDialog.c b/win/tkWinDialog.c
index af512ad..b1ae29c 100644
--- a/win/tkWinDialog.c
+++ b/win/tkWinDialog.c
@@ -8,7 +8,7 @@
  * See the file "license.terms" for information on usage and redistribution
  * of this file, and for a DISCLAIMER OF ALL WARRANTIES.
  *
- * RCS: @(#) $Id: tkWinDialog.c,v 1.30.2.3 2004/08/20 00:40:32 hobbs Exp $
+ * RCS: @(#) $Id: tkWinDialog.c,v 1.30.2.4 2004/08/20 01:14:20 hobbs Exp $
  *
  */
 
@@ -63,7 +63,7 @@ typedef struct ThreadSpecificData {
 			       * communicating between the Directory
 			       * Chooser dialog and its hook proc. */
     HHOOK hMsgBoxHook;        /* Hook proc for tk_messageBox and the */
-    HICON hSmallIcon;	      /* icons used by a parent to be used in */
+    HICON hSmallIcon;         /* icons used by a parent to be used in */
     HICON hBigIcon;           /* the message box */
 } ThreadSpecificData;
 static Tcl_ThreadDataKey dataKey;
@@ -177,7 +177,53 @@ static UINT APIENTRY	OFNHookProcW(HWND hdlg, UINT uMsg, WPARAM wParam,
 			    LPARAM lParam);
 static LRESULT CALLBACK MsgBoxCBTProc(int nCode, WPARAM wParam, LPARAM lParam);
 static void		SetTkDialog(ClientData clientData);
+
+/*
+ *-------------------------------------------------------------------------
+ *
+ * EatSpuriousMessageBugFix --
+ *
+ *	In the file open/save dialog, double clicking on a list item
+ *	causes the dialog box to close, but an unwanted WM_LBUTTONUP
+ * 	message is sent to the window underneath. If the window underneath
+ * 	happens to be a windows control (eg a button) then it will be
+ * 	activated by accident.
+ *
+ * 	This problem does not occur in dialog boxes, because windows
+ * 	must do some special processing to solve the problem. (separate
+ * 	message processing functions are used to cope with keyboard
+ * 	navigation of controls.)
+ *
+ * 	Here is one solution. After returning, we poll the message queue
+ * 	for 200ms 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.
+ *
+ * Results:
+ *	None.
+ *
+ * Side effects:
+ *	Consumes an unwanted BUTTON messages.
+ *
+ *-------------------------------------------------------------------------
+ */
 
+static void
+EatSpuriousMessageBugFix(void)
+{
+    MSG msg;
+    DWORD nTime = GetTickCount() + 200;
+    while (GetTickCount() < nTime) {
+	if (PeekMessage(&msg,0,WM_LBUTTONDOWN,WM_LBUTTONDOWN,PM_NOREMOVE)) {
+	    break;
+	}
+	PeekMessage(&msg,0,WM_LBUTTONUP,WM_LBUTTONUP,PM_REMOVE);
+    }
+}
+
 /*
  *-------------------------------------------------------------------------
  *
@@ -737,6 +783,7 @@ GetFileNameW(clientData, interp, objc, objv, open)
 	winCode = GetSaveFileNameW(&ofn);
     }
     Tcl_SetServiceMode(oldMode);
+    EatSpuriousMessageBugFix();
 
     /*
      * Ensure that hWnd is enabled, because it can happen that we
@@ -1221,6 +1268,7 @@ GetFileNameA(clientData, interp, objc, objv, open)
 	winCode = GetSaveFileName(&ofn);
     }
     Tcl_SetServiceMode(oldMode);
+    EatSpuriousMessageBugFix();
     SetCurrentDirectory(savePath);
 
     /*