After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 104944 - Clipboard frozen w/ GtkTextView right mouse click
Clipboard frozen w/ GtkTextView right mouse click
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.2.x
Other Windows
: Normal normal
: ---
Assigned To: Tor Lillqvist
gtk-bugs
: 124735 126277 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-01-31 21:59 UTC by Herman Bloggs
Modified: 2011-02-04 16:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Herman Bloggs 2003-01-31 21:59:48 UTC 
Right clicking a GtkTextView (producing a menu) and then getting rid of 
the menu without choosing an option, disables the windows clipboard. 
Selecting and copying something from the textview widget, re-enables the 
windows clipboard.
Comment 1 Tor Lillqvist 2003-02-01 20:32:12 UTC 
Confirmed. Very odd.
Comment 2 Matthias Clasen 2003-06-10 09:57:19 UTC 
Move remaining bugs off 2.2.2 target milestone.
Comment 3 Matthias Clasen 2003-08-27 08:05:57 UTC 
Move remaining bugs off the 2.2.3 milestone
Comment 4 Josh Steiner 2003-10-30 19:11:06 UTC 
*** Bug 124735 has been marked as a duplicate of this bug. ***
Comment 5 Adam Wright 2003-12-12 15:37:14 UTC 
As this one has bitten me (in use of GAIM), I've had a brief look.
Compiling the sources under Win32 looked rather daunting, so I've
based my investigations by browsing current CVS with Bonsai.

The most obvious reason for this to lock the clipboard will be
unmatched Open/CloseClipboard pairs. I suspect that in...

/gtk+/gdk/win32/gdkselection-win32.c

Insertion of...

		if (!CloseClipboard())
		{
			WIN32_API_FAILED ("CloseClipboard");
			return;
		}

At line 293 of said file (the base of the branch...

270     if (selection == GDK_SELECTION_CLIPBOARD &&
271       target == gdk_atom_intern ("TARGETS", FALSE))
272     {

)

should fix the only case of unmatched openings I can find. The second
branch in that if block does also OpenClipboard, but has the
corresponding close.

If this all turns out to be garbage, please accept my apologies - if
anyone has some instructions on how to get GTK+ building on Win32, I'd
be very happy to go off, fix this and provide a proper patch.

Cheers,

adamw
Comment 6 Tor Lillqvist 2003-12-14 02:20:29 UTC 
Thanks! Very good catch, especially from just reading the code. Fix 
applied to gtk-2-2 and HEAD.
Comment 7 Tor Lillqvist 2003-12-14 02:30:24 UTC 
*** Bug 126277 has been marked as a duplicate of this bug. ***