summaryrefslogtreecommitdiffstats
path: root/win
diff options
context:
space:
mode:
authorpatthoyts <patthoyts@users.sourceforge.net>2003-07-28 22:12:33 (GMT)
committerpatthoyts <patthoyts@users.sourceforge.net>2003-07-28 22:12:33 (GMT)
commitfa19958f1af0e3e9b70717d9508f5f2a1ccf180e (patch)
tree74c58b47b8ba35c732fe22ba00f3e3aaf87d0cbb /win
parent5fffee7b1c13de3e7bbcd8893e48d02a259a9b4d (diff)
downloadtk-fa19958f1af0e3e9b70717d9508f5f2a1ccf180e.zip
tk-fa19958f1af0e3e9b70717d9508f5f2a1ccf180e.tar.gz
tk-fa19958f1af0e3e9b70717d9508f5f2a1ccf180e.tar.bz2
* win/tkWinDialog.c: Applied patch from bug #611615 which fixes a
problem with double clicks in file dialogs falling through to the window underneath in win32.
Diffstat (limited to 'win')
-rw-r--r--win/tkWinDialog.c53
1 files changed, 52 insertions, 1 deletions
diff --git a/win/tkWinDialog.c b/win/tkWinDialog.c
index 852eb00..9d2bee1 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.31 2003/07/18 19:50:20 hobbs Exp $
+ * RCS: @(#) $Id: tkWinDialog.c,v 1.32 2003/07/28 22:12:33 patthoyts Exp $
*
*/
@@ -174,6 +174,55 @@ static UINT APIENTRY OFNHookProcW(HWND hdlg, UINT uMsg, 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 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.
+ *
+ * Results:
+ * None.
+ *
+ * Side effects:
+ * Consumes an unwanted BUTTON messages.
+ *
+ *-------------------------------------------------------------------------
+ */
+
+static void EatSpuriousMessageBugFix( void )
+{
+ MSG msg;
+ DWORD nTime = GetTickCount() + 250;
+ while( GetTickCount() < nTime )
+ {
+ if( PeekMessage(&msg,0,WM_LBUTTONDOWN,WM_LBUTTONDOWN,PM_NOREMOVE) )
+ break;
+ PeekMessage(&msg,0,WM_LBUTTONUP,WM_LBUTTONUP,PM_REMOVE);
+ }
+}
+
+
+
/*
*-------------------------------------------------------------------------
*
@@ -733,6 +782,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
@@ -1217,6 +1267,7 @@ GetFileNameA(clientData, interp, objc, objv, open)
winCode = GetSaveFileName(&ofn);
}
Tcl_SetServiceMode(oldMode);
+ EatSpuriousMessageBugFix();
SetCurrentDirectory(savePath);
/*