Details
Description
I once closed five instances of Tableau, a Qt application, and even though the windows disappeared, the processes were hung on system calls to ChangeClipboardChain().
QWindowsClipboard uses the old Windows clipboard chain API (ChangeClipboardChain) to receive notifications when the clipboard contents change. This API is a badly-designed way for Windows applications to receive clipboard change events – see http://stackoverflow.com/questions/5709311/can-aborting-a-process-without-resetting-the-clipboard-chain-cause-trouble. Any badly-behaving process that uses the clipboard chain could mess the other processes up, even if they handle the clipboard chain correctly.
An easy fix for Vista and later would be to use AddClipboardFormatListener() and RemoveClipboardFormatListener() in QWindowsClipboard, and change the clipboard message Qt listens for. If there's a way to check for this conditionally, it may be a worthwhile and minor change that makes Qt Windows apps more robust.
Additionally, it would be nice to have the option to not run the clipboard listening mechanism in QWindowClipboard, as many applications don't care if the clipboard changes. For example, perhaps the hidden listening window could be created as soon as a slot is registered with the QClipboard::changed/dataChanged signals.
Attachments
Issue Links
- is duplicated by
-
QTBUG-39831 QClipboard::changed not emitted when a QLocalSocket abnormally disconnects
- Closed
- relates to
-
QTBUG-38398 Copying to clipboard fails with CO_E_NOTINITIALIZED error when linked with C++/CLR library
- Closed
-
QTBUG-33492 Clipboard does not work during debugging
- Closed
-
QTCREATORBUG-3818 Copy & paste from debugged process freezes Creator
- Reported
- resulted in
-
QTBUG-39145 tst_qquicktextinput fails in qtdeclarative#dev
- Closed