2003-11-14 17:48:57 +01:00
|
|
|
/*
|
2004-06-21 15:19:32 +02:00
|
|
|
*Copyright (C) 2003-2004 Harold L Hunt II All Rights Reserved.
|
2009-02-03 16:48:04 +01:00
|
|
|
*Copyright (C) Colin Harrison 2005-2008
|
2003-11-14 17:48:57 +01:00
|
|
|
*
|
|
|
|
*Permission is hereby granted, free of charge, to any person obtaining
|
|
|
|
* a copy of this software and associated documentation files (the
|
|
|
|
*"Software"), to deal in the Software without restriction, including
|
|
|
|
*without limitation the rights to use, copy, modify, merge, publish,
|
|
|
|
*distribute, sublicense, and/or sell copies of the Software, and to
|
|
|
|
*permit persons to whom the Software is furnished to do so, subject to
|
|
|
|
*the following conditions:
|
|
|
|
*
|
|
|
|
*The above copyright notice and this permission notice shall be
|
|
|
|
*included in all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
*THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
*EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
*MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
2004-06-21 15:19:32 +02:00
|
|
|
*NONINFRINGEMENT. IN NO EVENT SHALL HAROLD L HUNT II BE LIABLE FOR
|
2003-11-14 17:48:57 +01:00
|
|
|
*ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
|
|
|
|
*CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
|
|
|
*WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
*
|
2009-02-03 16:48:04 +01:00
|
|
|
*Except as contained in this notice, the name of the copyright holder(s)
|
|
|
|
*and author(s) shall not be used in advertising or otherwise to promote
|
|
|
|
*the sale, use or other dealings in this Software without prior written
|
|
|
|
*authorization from the copyright holder(s) and author(s).
|
2003-11-14 17:48:57 +01:00
|
|
|
*
|
|
|
|
* Authors: Harold L Hunt II
|
2009-02-03 16:48:04 +01:00
|
|
|
* Colin Harrison
|
2003-11-14 17:48:57 +01:00
|
|
|
*/
|
|
|
|
|
2005-07-05 00:10:43 +02:00
|
|
|
#ifdef HAVE_XWIN_CONFIG_H
|
|
|
|
#include <xwin-config.h>
|
|
|
|
#endif
|
2013-06-17 19:27:56 +02:00
|
|
|
|
2013-06-19 14:09:35 +02:00
|
|
|
/*
|
|
|
|
* Including any server header might define the macro _XSERVER64 on 64 bit machines.
|
|
|
|
* That macro must _NOT_ be defined for Xlib client code, otherwise bad things happen.
|
|
|
|
* So let's undef that macro if necessary.
|
|
|
|
*/
|
|
|
|
#ifdef _XSERVER64
|
|
|
|
#undef _XSERVER64
|
|
|
|
#endif
|
|
|
|
|
2005-07-05 00:10:43 +02:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/time.h>
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
#include <limits.h>
|
2013-06-17 19:27:56 +02:00
|
|
|
|
2013-06-20 13:50:18 +02:00
|
|
|
#include <X11/Xatom.h>
|
|
|
|
|
2013-06-17 19:27:56 +02:00
|
|
|
#include "internal.h"
|
|
|
|
#include "winclipboard.h"
|
2003-11-14 17:48:57 +01:00
|
|
|
|
2004-06-21 15:19:32 +02:00
|
|
|
/*
|
|
|
|
* Constants
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define WIN_POLL_TIMEOUT 1
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process X events up to specified timeout
|
|
|
|
*/
|
|
|
|
|
|
|
|
static int
|
2013-06-18 20:28:53 +02:00
|
|
|
winProcessXEventsTimeout(HWND hwnd, Window iWindow, Display * pDisplay,
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
ClipboardConversionData *data, ClipboardAtoms *atoms, int iTimeoutSec)
|
2004-06-21 15:19:32 +02:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
int iConnNumber;
|
|
|
|
struct timeval tv;
|
|
|
|
int iReturn;
|
2012-07-21 15:13:37 +02:00
|
|
|
DWORD dwStopTime = GetTickCount() + iTimeoutSec * 1000;
|
2012-03-21 20:55:09 +01:00
|
|
|
|
2012-07-21 15:13:37 +02:00
|
|
|
winDebug("winProcessXEventsTimeout () - pumping X events for %d seconds\n",
|
|
|
|
iTimeoutSec);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/* Get our connection number */
|
|
|
|
iConnNumber = ConnectionNumber(pDisplay);
|
|
|
|
|
|
|
|
/* Loop for X events */
|
|
|
|
while (1) {
|
|
|
|
fd_set fdsRead;
|
2012-07-21 15:13:37 +02:00
|
|
|
long remainingTime;
|
|
|
|
|
2013-11-21 16:18:48 +01:00
|
|
|
/* Process X events */
|
|
|
|
iReturn = winClipboardFlushXEvents(hwnd, iWindow, pDisplay, data, atoms);
|
|
|
|
|
|
|
|
winDebug("winProcessXEventsTimeout () - winClipboardFlushXEvents returned %d\n", iReturn);
|
|
|
|
|
|
|
|
if ((WIN_XEVENTS_NOTIFY_DATA == iReturn) || (WIN_XEVENTS_NOTIFY_TARGETS == iReturn) || (WIN_XEVENTS_FAILED == iReturn)) {
|
|
|
|
/* Bail out */
|
|
|
|
return iReturn;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We need to ensure that all pending requests are sent */
|
|
|
|
XFlush(pDisplay);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/* Setup the file descriptor set */
|
|
|
|
FD_ZERO(&fdsRead);
|
|
|
|
FD_SET(iConnNumber, &fdsRead);
|
|
|
|
|
|
|
|
/* Adjust timeout */
|
2012-07-21 15:13:37 +02:00
|
|
|
remainingTime = dwStopTime - GetTickCount();
|
|
|
|
tv.tv_sec = remainingTime / 1000;
|
|
|
|
tv.tv_usec = (remainingTime % 1000) * 1000;
|
|
|
|
winDebug("winProcessXEventsTimeout () - %d milliseconds left\n",
|
|
|
|
remainingTime);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/* Break out if no time left */
|
2012-07-21 15:13:37 +02:00
|
|
|
if (remainingTime <= 0)
|
2012-03-21 20:55:09 +01:00
|
|
|
return WIN_XEVENTS_SUCCESS;
|
|
|
|
|
|
|
|
/* Wait for an X event */
|
|
|
|
iReturn = select(iConnNumber + 1, /* Highest fds number */
|
|
|
|
&fdsRead, /* Read mask */
|
|
|
|
NULL, /* No write mask */
|
|
|
|
NULL, /* No exception mask */
|
2012-07-21 15:13:37 +02:00
|
|
|
&tv); /* Timeout */
|
2012-03-21 20:55:09 +01:00
|
|
|
if (iReturn < 0) {
|
|
|
|
ErrorF("winProcessXEventsTimeout - Call to select () failed: %d. "
|
|
|
|
"Bailing.\n", iReturn);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-11-21 16:18:48 +01:00
|
|
|
if (!FD_ISSET(iConnNumber, &fdsRead)) {
|
|
|
|
winDebug("winProcessXEventsTimeout - Spurious wake, select() returned %d\n", iReturn);
|
2012-07-21 15:13:37 +02:00
|
|
|
}
|
2004-06-21 15:19:32 +02:00
|
|
|
}
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
return WIN_XEVENTS_SUCCESS;
|
2004-06-21 15:19:32 +02:00
|
|
|
}
|
|
|
|
|
2003-11-14 17:48:57 +01:00
|
|
|
/*
|
|
|
|
* Process a given Windows message
|
|
|
|
*/
|
|
|
|
|
|
|
|
LRESULT CALLBACK
|
2012-03-21 20:55:09 +01:00
|
|
|
winClipboardWindowProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
|
2003-11-14 17:48:57 +01:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
static HWND s_hwndNextViewer;
|
|
|
|
static Bool s_fCBCInitialized;
|
2013-06-16 23:35:22 +02:00
|
|
|
static Display *pDisplay;
|
|
|
|
static Window iWindow;
|
2013-06-17 20:58:20 +02:00
|
|
|
static ClipboardAtoms *atoms;
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
static Bool fRunning;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
/* Branch on message type */
|
|
|
|
switch (message) {
|
2003-11-14 17:48:57 +01:00
|
|
|
case WM_DESTROY:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
|
|
|
winDebug("winClipboardWindowProc - WM_DESTROY\n");
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
/* Remove ourselves from the clipboard chain */
|
|
|
|
ChangeClipboardChain(hwnd, s_hwndNextViewer);
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
s_hwndNextViewer = NULL;
|
hw/xwin: Fix clipboard thread restart
It seems that the clipboard thread restart mechanism has been broken for a
while, which can be demonstrated using XDMCP with KDM (e.g. to a Kubutunu 12.04
host)
KDM kills all attached clients, including the clipboard integration client,
which restarts, but then exits on WM_QUIT.
Using PostQuitMessage() in WM_DESTROY is unhelpful, as we may not actually be
quitting the thread, if we just destroyed the window because the clipboard
thread is about to retry, because he WM_QUIT message sticks around, and is
noticed the next time we look at the window message queue and confuses us into
thinking we need to quit.
Sending a WM_DESTROY is apparently never correct anyhow, see [1]
So:
1/ Use DestroyWindow() to destroy the clipboard messaging window when cleaning
up for retry or exit in winClipboardProc (the clipboard thread main proc)
2/ Send a special WM_WM_QUIT message in winClipboardWindowDestroy() from the X
server thread when the X server is resetting.
3/ When processing that WM_WM_QUIT message in the clipboard thread, cause the
clipboard window to PostQuitMessage(), which causes the clipboard thread to
exit.
[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-02-22 00:20:00 +01:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
case WM_WM_QUIT:
|
|
|
|
{
|
|
|
|
winDebug("winClipboardWindowProc - WM_WM_QUIT\n");
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
fRunning = FALSE;
|
2012-03-21 20:55:09 +01:00
|
|
|
PostQuitMessage(0);
|
|
|
|
}
|
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2003-11-14 17:48:57 +01:00
|
|
|
case WM_CREATE:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
|
|
|
HWND first, next;
|
|
|
|
DWORD error_code = 0;
|
2013-06-16 23:35:22 +02:00
|
|
|
ClipboardWindowCreationParams *cwcp = (ClipboardWindowCreationParams *)((CREATESTRUCT *)lParam)->lpCreateParams;
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - WM_CREATE\n");
|
|
|
|
|
2013-06-16 23:35:22 +02:00
|
|
|
pDisplay = cwcp->pClipboardDisplay;
|
|
|
|
iWindow = cwcp->iClipboardWindow;
|
2013-06-17 20:58:20 +02:00
|
|
|
atoms = cwcp->atoms;
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
fRunning = TRUE;
|
2013-06-16 23:35:22 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
first = GetClipboardViewer(); /* Get handle to first viewer in chain. */
|
|
|
|
if (first == hwnd)
|
|
|
|
return 0; /* Make sure it's not us! */
|
|
|
|
/* Add ourselves to the clipboard viewer chain */
|
|
|
|
next = SetClipboardViewer(hwnd);
|
|
|
|
error_code = GetLastError();
|
|
|
|
if (SUCCEEDED(error_code) && (next == first)) /* SetClipboardViewer must have succeeded, and the handle */
|
|
|
|
s_hwndNextViewer = next; /* it returned must have been the first window in the chain */
|
|
|
|
else
|
|
|
|
s_fCBCInitialized = FALSE;
|
|
|
|
}
|
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
|
|
|
case WM_CHANGECBCHAIN:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
|
|
|
winDebug("winClipboardWindowProc - WM_CHANGECBCHAIN: wParam(%x) "
|
|
|
|
"lParam(%x) s_hwndNextViewer(%x)\n",
|
|
|
|
wParam, lParam, s_hwndNextViewer);
|
|
|
|
|
|
|
|
if ((HWND) wParam == s_hwndNextViewer) {
|
|
|
|
s_hwndNextViewer = (HWND) lParam;
|
|
|
|
if (s_hwndNextViewer == hwnd) {
|
|
|
|
s_hwndNextViewer = NULL;
|
2013-06-17 21:03:04 +02:00
|
|
|
ErrorF("winClipboardWindowProc - WM_CHANGECBCHAIN: "
|
|
|
|
"attempted to set next window to ourselves.");
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (s_hwndNextViewer)
|
|
|
|
SendMessage(s_hwndNextViewer, message, wParam, lParam);
|
|
|
|
|
|
|
|
}
|
|
|
|
winDebug("winClipboardWindowProc - WM_CHANGECBCHAIN: Exit\n");
|
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
|
|
|
case WM_WM_REINIT:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
2004-06-21 15:19:32 +02:00
|
|
|
/* Ensure that we're in the clipboard chain. Some apps,
|
|
|
|
* WinXP's remote desktop for one, don't play nice with the
|
|
|
|
* chain. This message is called whenever we receive a
|
|
|
|
* WM_ACTIVATEAPP message to ensure that we continue to
|
|
|
|
* receive clipboard messages.
|
2012-03-21 20:55:09 +01:00
|
|
|
*
|
|
|
|
* It might be possible to detect if we're still in the chain
|
|
|
|
* by calling SendMessage (GetClipboardViewer(),
|
|
|
|
* WM_DRAWCLIPBOARD, 0, 0); and then seeing if we get the
|
|
|
|
* WM_DRAWCLIPBOARD message. That, however, might be more
|
|
|
|
* expensive than just putting ourselves back into the chain.
|
|
|
|
*/
|
|
|
|
|
|
|
|
HWND first, next;
|
|
|
|
DWORD error_code = 0;
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - WM_WM_REINIT: Enter\n");
|
|
|
|
|
|
|
|
first = GetClipboardViewer(); /* Get handle to first viewer in chain. */
|
|
|
|
if (first == hwnd)
|
|
|
|
return 0; /* Make sure it's not us! */
|
|
|
|
winDebug(" WM_WM_REINIT: Replacing us(%x) with %x at head "
|
|
|
|
"of chain\n", hwnd, s_hwndNextViewer);
|
|
|
|
s_fCBCInitialized = FALSE;
|
|
|
|
ChangeClipboardChain(hwnd, s_hwndNextViewer);
|
|
|
|
s_hwndNextViewer = NULL;
|
|
|
|
s_fCBCInitialized = FALSE;
|
|
|
|
winDebug(" WM_WM_REINIT: Putting us back at head of chain.\n");
|
|
|
|
first = GetClipboardViewer(); /* Get handle to first viewer in chain. */
|
|
|
|
if (first == hwnd)
|
|
|
|
return 0; /* Make sure it's not us! */
|
|
|
|
next = SetClipboardViewer(hwnd);
|
|
|
|
error_code = GetLastError();
|
|
|
|
if (SUCCEEDED(error_code) && (next == first)) /* SetClipboardViewer must have succeeded, and the handle */
|
|
|
|
s_hwndNextViewer = next; /* it returned must have been the first window in the chain */
|
|
|
|
else
|
|
|
|
s_fCBCInitialized = FALSE;
|
|
|
|
}
|
|
|
|
winDebug("winClipboardWindowProc - WM_WM_REINIT: Exit\n");
|
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
|
|
|
case WM_DRAWCLIPBOARD:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
|
|
|
static Bool s_fProcessingDrawClipboard = FALSE;
|
|
|
|
int iReturn;
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD: Enter\n");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We've occasionally seen a loop in the clipboard chain.
|
|
|
|
* Try and fix it on the first hint of recursion.
|
|
|
|
*/
|
|
|
|
if (!s_fProcessingDrawClipboard) {
|
|
|
|
s_fProcessingDrawClipboard = TRUE;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* Attempt to break the nesting by getting out of the chain, twice?, and then fix and bail */
|
|
|
|
s_fCBCInitialized = FALSE;
|
|
|
|
ChangeClipboardChain(hwnd, s_hwndNextViewer);
|
|
|
|
winFixClipboardChain();
|
2013-06-17 21:03:04 +02:00
|
|
|
ErrorF("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"Nested calls detected. Re-initing.\n");
|
2012-03-21 20:55:09 +01:00
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD: Exit\n");
|
|
|
|
s_fProcessingDrawClipboard = FALSE;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Bail on first message */
|
|
|
|
if (!s_fCBCInitialized) {
|
|
|
|
s_fCBCInitialized = TRUE;
|
|
|
|
s_fProcessingDrawClipboard = FALSE;
|
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD: Exit\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE: We cannot bail out when NULL == GetClipboardOwner ()
|
|
|
|
* because some applications deal with the clipboard in a manner
|
|
|
|
* that causes the clipboard owner to be NULL when they are in
|
|
|
|
* fact taking ownership. One example of this is the Win32
|
|
|
|
* native compile of emacs.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Bail when we still own the clipboard */
|
|
|
|
if (hwnd == GetClipboardOwner()) {
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"We own the clipboard, returning.\n");
|
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD: Exit\n");
|
|
|
|
s_fProcessingDrawClipboard = FALSE;
|
|
|
|
if (s_hwndNextViewer)
|
|
|
|
SendMessage(s_hwndNextViewer, message, wParam, lParam);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
/* Bail when shutting down */
|
|
|
|
if (!fRunning)
|
|
|
|
return 0;
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
/*
|
|
|
|
* Do not take ownership of the X11 selections when something
|
|
|
|
* other than CF_TEXT or CF_UNICODETEXT has been copied
|
|
|
|
* into the Win32 clipboard.
|
|
|
|
*/
|
|
|
|
if (!IsClipboardFormatAvailable(CF_TEXT)
|
|
|
|
&& !IsClipboardFormatAvailable(CF_UNICODETEXT)) {
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"Clipboard does not contain CF_TEXT nor "
|
|
|
|
"CF_UNICODETEXT.\n");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to make sure that the X Server has processed
|
|
|
|
* previous XSetSelectionOwner messages.
|
|
|
|
*/
|
|
|
|
XSync(pDisplay, FALSE);
|
2010-02-19 03:37:00 +01:00
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - XSync done.\n");
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
/* Release PRIMARY selection if owned */
|
|
|
|
iReturn = XGetSelectionOwner(pDisplay, XA_PRIMARY);
|
2013-06-16 23:35:22 +02:00
|
|
|
if (iReturn == iWindow) {
|
2012-03-21 20:55:09 +01:00
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"PRIMARY selection is owned by us.\n");
|
|
|
|
XSetSelectionOwner(pDisplay, XA_PRIMARY, None, CurrentTime);
|
|
|
|
}
|
|
|
|
else if (BadWindow == iReturn || BadAtom == iReturn)
|
2013-06-17 21:03:04 +02:00
|
|
|
ErrorF("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"XGetSelectionOwner failed for PRIMARY: %d\n",
|
|
|
|
iReturn);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/* Release CLIPBOARD selection if owned */
|
2013-06-17 20:58:20 +02:00
|
|
|
iReturn = XGetSelectionOwner(pDisplay, atoms->atomClipboard);
|
2013-06-16 23:35:22 +02:00
|
|
|
if (iReturn == iWindow) {
|
2012-03-21 20:55:09 +01:00
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
2013-06-17 20:58:20 +02:00
|
|
|
"CLIPBOARD selection is owned by us, releasing\n");
|
|
|
|
XSetSelectionOwner(pDisplay, atoms->atomClipboard, None, CurrentTime);
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
else if (BadWindow == iReturn || BadAtom == iReturn)
|
2013-06-17 21:03:04 +02:00
|
|
|
ErrorF("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"XGetSelectionOwner failed for CLIPBOARD: %d\n",
|
|
|
|
iReturn);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD: Exit\n");
|
|
|
|
s_fProcessingDrawClipboard = FALSE;
|
|
|
|
if (s_hwndNextViewer)
|
|
|
|
SendMessage(s_hwndNextViewer, message, wParam, lParam);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Reassert ownership of PRIMARY */
|
|
|
|
iReturn = XSetSelectionOwner(pDisplay,
|
|
|
|
XA_PRIMARY, iWindow, CurrentTime);
|
|
|
|
if (iReturn == BadAtom || iReturn == BadWindow ||
|
|
|
|
XGetSelectionOwner(pDisplay, XA_PRIMARY) != iWindow) {
|
2013-06-17 21:03:04 +02:00
|
|
|
ErrorF("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"Could not reassert ownership of PRIMARY\n");
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"Reasserted ownership of PRIMARY\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Reassert ownership of the CLIPBOARD */
|
|
|
|
iReturn = XSetSelectionOwner(pDisplay,
|
2013-06-17 20:58:20 +02:00
|
|
|
atoms->atomClipboard, iWindow, CurrentTime);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
if (iReturn == BadAtom || iReturn == BadWindow ||
|
2013-06-17 20:58:20 +02:00
|
|
|
XGetSelectionOwner(pDisplay, atoms->atomClipboard) != iWindow) {
|
2013-06-17 21:03:04 +02:00
|
|
|
ErrorF("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"Could not reassert ownership of CLIPBOARD\n");
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD - "
|
|
|
|
"Reasserted ownership of CLIPBOARD\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flush the pending SetSelectionOwner event now */
|
|
|
|
XFlush(pDisplay);
|
|
|
|
|
|
|
|
s_fProcessingDrawClipboard = FALSE;
|
|
|
|
}
|
|
|
|
winDebug("winClipboardWindowProc - WM_DRAWCLIPBOARD: Exit\n");
|
|
|
|
/* Pass the message on the next window in the clipboard viewer chain */
|
|
|
|
if (s_hwndNextViewer)
|
|
|
|
SendMessage(s_hwndNextViewer, message, wParam, lParam);
|
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
|
|
|
case WM_DESTROYCLIPBOARD:
|
2012-03-21 20:55:09 +01:00
|
|
|
/*
|
|
|
|
* NOTE: Intentionally do nothing.
|
|
|
|
* Changes in the Win32 clipboard are handled by WM_DRAWCLIPBOARD
|
|
|
|
* above. We only process this message to conform to the specs
|
|
|
|
* for delayed clipboard rendering in Win32. You might think
|
|
|
|
* that we need to release ownership of the X11 selections, but
|
|
|
|
* we do not, because a WM_DRAWCLIPBOARD message will closely
|
|
|
|
* follow this message and reassert ownership of the X11
|
|
|
|
* selections, handling the issue for us.
|
|
|
|
*/
|
|
|
|
winDebug("winClipboardWindowProc - WM_DESTROYCLIPBOARD - Ignored.\n");
|
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
|
|
|
case WM_RENDERALLFORMATS:
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_RENDERALLFORMATS - Hello.\n");
|
|
|
|
|
|
|
|
/*
|
|
|
|
WM_RENDERALLFORMATS is sent as we are shutting down, to render the
|
|
|
|
clipboard so it's contents remains available to other applications.
|
|
|
|
|
|
|
|
Unfortunately, this can't work without major changes. The server is
|
|
|
|
already waiting for us to stop, so we can't ask for the rendering of
|
|
|
|
clipboard text now.
|
|
|
|
*/
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
case WM_RENDERFORMAT:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
|
|
|
int iReturn;
|
|
|
|
Bool fConvertToUnicode;
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
Bool pasted = FALSE;
|
|
|
|
Atom selection;
|
|
|
|
ClipboardConversionData data;
|
|
|
|
int best_target = 0;
|
2012-03-21 20:55:09 +01:00
|
|
|
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_RENDERFORMAT %d - Hello.\n",
|
|
|
|
wParam);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/* Flag whether to convert to Unicode or not */
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
fConvertToUnicode = (CF_UNICODETEXT == wParam);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
selection = winClipboardGetLastOwnedSelectionAtom(atoms);
|
|
|
|
if (selection == None) {
|
|
|
|
ErrorF("winClipboardWindowProc - no monitored selection is owned\n");
|
|
|
|
goto fake_paste;
|
|
|
|
}
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - requesting targets for selection from owner\n");
|
|
|
|
|
|
|
|
/* Request the selection's supported conversion targets */
|
|
|
|
XConvertSelection(pDisplay,
|
|
|
|
selection,
|
|
|
|
atoms->atomTargets,
|
|
|
|
atoms->atomLocalProperty,
|
|
|
|
iWindow, CurrentTime);
|
|
|
|
|
|
|
|
/* Process X events */
|
|
|
|
data.fUseUnicode = fConvertToUnicode;
|
|
|
|
iReturn = winProcessXEventsTimeout(hwnd,
|
|
|
|
iWindow,
|
|
|
|
pDisplay,
|
|
|
|
&data,
|
|
|
|
atoms,
|
|
|
|
WIN_POLL_TIMEOUT);
|
|
|
|
|
|
|
|
if (WIN_XEVENTS_NOTIFY_TARGETS != iReturn) {
|
|
|
|
ErrorF
|
|
|
|
("winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_TARGETS\n");
|
|
|
|
goto fake_paste;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Choose the most preferred target */
|
|
|
|
{
|
|
|
|
struct target_priority
|
|
|
|
{
|
|
|
|
Atom target;
|
|
|
|
unsigned int priority;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct target_priority target_priority_table[] =
|
|
|
|
{
|
|
|
|
{ atoms->atomCompoundText, 0 },
|
|
|
|
#ifdef X_HAVE_UTF8_STRING
|
|
|
|
{ atoms->atomUTF8String, 1 },
|
|
|
|
#endif
|
|
|
|
{ XA_STRING, 2 },
|
|
|
|
};
|
|
|
|
|
|
|
|
int best_priority = INT_MAX;
|
|
|
|
|
|
|
|
int i,j;
|
|
|
|
for (i = 0 ; data.targetList[i] != 0; i++)
|
|
|
|
{
|
|
|
|
for (j = 0; j < sizeof(target_priority_table)/sizeof(struct target_priority); j ++)
|
|
|
|
{
|
|
|
|
if ((data.targetList[i] == target_priority_table[j].target) &&
|
|
|
|
(target_priority_table[j].priority < best_priority))
|
|
|
|
{
|
|
|
|
best_target = target_priority_table[j].target;
|
|
|
|
best_priority = target_priority_table[j].priority;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
free(data.targetList);
|
|
|
|
data.targetList = 0;
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - best target is %d\n", best_target);
|
|
|
|
|
|
|
|
/* No useful targets found */
|
|
|
|
if (best_target == 0)
|
|
|
|
goto fake_paste;
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - requesting selection from owner\n");
|
|
|
|
|
|
|
|
/* Request the selection contents */
|
|
|
|
XConvertSelection(pDisplay,
|
|
|
|
selection,
|
|
|
|
best_target,
|
|
|
|
atoms->atomLocalProperty,
|
|
|
|
iWindow, CurrentTime);
|
|
|
|
|
|
|
|
/* Process X events */
|
2012-03-21 20:55:09 +01:00
|
|
|
iReturn = winProcessXEventsTimeout(hwnd,
|
|
|
|
iWindow,
|
|
|
|
pDisplay,
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
&data,
|
2013-06-17 20:58:20 +02:00
|
|
|
atoms,
|
|
|
|
WIN_POLL_TIMEOUT);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/*
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
* winProcessXEventsTimeout had better have seen a notify event,
|
|
|
|
* or else we are dealing with a buggy or old X11 app.
|
2012-03-21 20:55:09 +01:00
|
|
|
*/
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
if (WIN_XEVENTS_NOTIFY_DATA != iReturn) {
|
|
|
|
ErrorF
|
|
|
|
("winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_DATA\n");
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
pasted = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we couldn't get the data from the X clipboard, we
|
|
|
|
* have to paste some fake data to the Win32 clipboard to
|
|
|
|
* satisfy the requirement that we write something to it.
|
|
|
|
*/
|
|
|
|
fake_paste:
|
|
|
|
if (!pasted)
|
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
/* Paste no data, to satisfy required call to SetClipboardData */
|
2012-07-05 23:08:38 +02:00
|
|
|
SetClipboardData(CF_UNICODETEXT, NULL);
|
2012-03-21 20:55:09 +01:00
|
|
|
SetClipboardData(CF_TEXT, NULL);
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
}
|
2012-03-21 20:55:09 +01:00
|
|
|
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_RENDERFORMAT - Returning.\n");
|
2012-03-21 20:55:09 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2003-11-14 17:48:57 +01:00
|
|
|
}
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
/* Let Windows perform default processing for unhandled messages */
|
|
|
|
return DefWindowProc(hwnd, message, wParam, lParam);
|
2003-11-14 17:48:57 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process any pending Windows messages
|
|
|
|
*/
|
|
|
|
|
2013-06-20 13:50:18 +02:00
|
|
|
Bool
|
2012-03-21 20:55:09 +01:00
|
|
|
winClipboardFlushWindowsMessageQueue(HWND hwnd)
|
2003-11-14 17:48:57 +01:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
MSG msg;
|
|
|
|
|
|
|
|
/* Flush the messaging window queue */
|
|
|
|
/* NOTE: Do not pass the hwnd of our messaging window to PeekMessage,
|
|
|
|
* as this will filter out many non-window-specific messages that
|
|
|
|
* are sent to our thread, such as WM_QUIT.
|
|
|
|
*/
|
|
|
|
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {
|
|
|
|
/* Dispatch the message if not WM_QUIT */
|
|
|
|
if (msg.message == WM_QUIT)
|
|
|
|
return FALSE;
|
|
|
|
else
|
|
|
|
DispatchMessage(&msg);
|
2003-11-14 17:48:57 +01:00
|
|
|
}
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
return TRUE;
|
2003-11-14 17:48:57 +01:00
|
|
|
}
|