GNOME Bugzilla – Bug 145156
alt+tab while LMB is pressed - missing focus-out or button-release events
Last modified: 2004-12-22 21:47:04 UTC
tested in gtk+-2.4.3 - tor's win32 binaries. In any application with buttons: 1) place the mouse cursor over a button, left-click and hold. 2) press and release alt+tab once, keeping LMB held, so that another application appears in front of ours. 3) let go of LMB while the mouse cursor is over the other application. 4) press and release alt+tab a second time, to switch back to our application. 5) move the cursor off the button, and back on again - the button behaves as if LMB was still held down. Notes: A signal handler connected to "focus_out_event" on the toplevel application GtkWindow will normally be called when alt+tab is used to switch away from the application. If LMB is held during the switch, the handler is not called. Likewise, a "focus_in_event" handler on the same window will normally be called when we switch back to the application, but it is not called if LMB had been held while we switched away. A signal handler connected to "button_release_event" on the toplevel application GtkWindow is normally called whenever a mouse button is released. If the mouse button was pressed and held during an application-switch, the handler is not called when the button is released if the cursor is over another application. If when the mouse button is pressed, the application constrains the cursor to a child-window (using the constrain-to-window option), the constraint persists after switching to another application while the mouse button is held down. When switching to another application with alt+tab, native win32 (eg. Explorer shell) seems to behave as if there was a focus-out, and as if all mouse buttons and keys were released. Comment: argh! this causes me pain =(
This seems to describe the same general problem as bug #107320, even if that talks about menus and not buttons. *** This bug has been marked as a duplicate of 107320 ***
I checked out bug #107320 before posting this one. There is one aspect in this bug that is not covered in bug #107320. Namely the fact that this bug only occurs if you hold a mouse button (eg. a GtkWindow has grabbed the cursor) while switching apps. It's possible that the fix for bug #129242 causes this bug...
Could you try reverting the (relatively straightforward) change in the fix for 129242, and see if it helps? If so, some serious head-scratching is required, because the problem that was fixed with that change was quite real, and I don't want to just revert it.
I haven't managed to successfully build gtk on win32 yet =). I've never managed to find up-to-date instructions on building with msvc.. but I haven't tried with mingw/gcc/pkgconfig. This is not through lack of desire - I'd really like to be able to hack the win32 ver, but building it seems beyond me =/. I'll try to build it this weekend and revert the part of the patch for bug #129242 that I think is related. Incidentally, I think it's down to the part that ignores the WM_KILLFOCUS message during a pointer grab. Perhaps there's a way to distinguish between a WM_KILLFOCUS message caused by a transient window of our app, and one caused by switching to another app.
I'd also like to have up-to-date instructions for building gtk+ on win32 with msvc. But cause I'm constantly doing it I don't have any problems which I can't solve. IMO the build instructions in glib/README.win32 are still valid. But if there is anything in between which stops you from building, please ask. Maybe we will be able to create an easier to follow version while getting you through the process ;-) Thanks, Hans
I didn't know of glib/README.win32... that helps a lot =). I finally managed to build a working version of gtk+-2.4.3 with nmake (msvc 7.10). A couple of things I noticed while hacking.. - gtk/stock-icons/makefile.msc is missing? - 'unresolved reference to pango_find_base_dir' .. the prebuilt pango-1.0.lib doesn't contain this symbol, but the prebuilt pango-1.0.dll exports it? I reverted the GDK_FOCUS_CHANGE_MASK part of the patch attached to bug #129242, and now I'm getting sensible focus-out and focus-in events on the toplevel window if I switch apps with a mouse button pressed. However, buttons still behave as in the original bug description - I guess they don't respond to the focus-out event.
Nice to here that the README.win32 does help ;) Strictly speaking gtk+ compiled with msvc 7.x is incompatible, that is some things will break when C-runtimes are mixed, like : - file-to-number mapping *nix open() taking a number and exchange them between dll s linked to another msvcrt. Visible effect e.g. is not properly reading rc files anymore (gtkrc is the most prominent example) - the whole GIMP plug-in system not being able to tak to the core anymore - 'random' crashes when calling malloc() from one C-runtime and free() from another But if all dependencies are built with one runtime it works. The official C-runtime for gtk+/win32 is msvcrt.dll - used by vc5 - vc6. stock-icons/makefile.msc : the file is in CVS but was missing in Makefile.am::EXTRA_DIST and thus in the tar.gz packages. Will be fixed with my next commit, at least on HEAD. pango_find_base_dir : a build issue (or installation?), can't do anything about it