GNOME Bugzilla – Bug 667792
Too much panic over OpenClipboard() failures
Last modified: 2018-04-14 23:59:40 UTC
gdk/win32/gdkproperty-win32.c, gdk_property_change(): if (!OpenClipboard (GDK_WINDOW_HWND (window))) { WIN32_API_FAILED ("OpenClipboard"); return; } gdk/win32/gdkdisplay-win32.c, inner_clipboard_window_procedure(): success = OpenClipboard (hwnd); g_return_val_if_fail (success, 0); gdk\win32\gdkselection-win32.c, gdk_selection_owner_set_for_display(): if (!API_CALL (OpenClipboard, (hwnd))) return FALSE; 1) I'm not sure it's a good idea to log at WARNING level (which is what WIN32_API_FAILED() and API_CALL() do) every time OpenClipboard() fails, because [quote from="MSDN"]OpenClipboard fails if another window has the clipboard open[/quote], so this is quite normal (if somewhat rare). 2) g_return_val_if_fail() in inner_clipboard_window_procedure() causes something like this to appear in the log: Gdk-CRITICAL **: inner_clipboard_window_procedure: assertion `success' failed Not nice. While i don't think there's a loss of functionality because of that (although i haven't checked the call chain all the way back to all possible initiators, and haven't checked how they react on failures), it's very annoying that GTK+ warns (including logging a critical assertion failure) about a condition that is not abnormal.
I had critical level exceptions set to fatal in my application: g_log_set_always_fatal((GLogLevelFlags)(G_LOG_FATAL_MASK|G_LOG_LEVEL_CRITICAL)); as it helps to find bugs in application faster. This caused my Windows GTK application to crash sometimes when "CTRL-C" was used in Microsoft Word or Excel, or sometimes when Word or Excel was closed after copying from it to GTK. GTk application did not even had focus. Please change it to a warning at most.
This is probably a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=706610
Jose, indeed, this is similar bug. It looks to me like a flawed clipboard API on win32, and missing error handling on gdk/gtk clipboard ops. Both of this make it practically impossible for applications to handle clipboard operations without failures with gdk. I think, unfortunately, that the busy loop I proposed in bug 706610 is our best bet for the moment to have a much reliable clipboard on windows... I welcome any suggestion, although I have think about various solutions too, none quite satisfactory.
Um...change the API to be asynchronous? Like, you call gtk_clipboard_open(...), which returns an event source id, which you can use to wait until clipboard actually opens. It will probably have to spawn a thread to wait until OpenClipboard() succeeds, because i don't see any W32API for doing that :(
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new