diff options
| author | Arnon Gilboa <agilboa@redhat.com> | 2012-03-01 13:06:24 +0200 |
|---|---|---|
| committer | Arnon Gilboa <agilboa@redhat.com> | 2012-03-01 14:18:57 +0200 |
| commit | 30f347e41ae768745d6ccb6711f1ca46ebfbe045 (patch) | |
| tree | e4f370791a1e39a7a4846557fcd5b8c290a7c07b /client/glz_decode_tmpl.c | |
| parent | 9d2bd519a33decc7dd54546459a7450aef47fcce (diff) | |
| download | spice-30f347e41ae768745d6ccb6711f1ca46ebfbe045.tar.gz spice-30f347e41ae768745d6ccb6711f1ca46ebfbe045.tar.xz spice-30f347e41ae768745d6ccb6711f1ca46ebfbe045.zip | |
client/windows: fix SetClipboardViewer error handling rhbz#786554
MSDN says the following about SetClipboardViewer(): "If an error occurs or there
are no other windows in the clipboard viewer chain, the return value is NULL".
Seems like the buggy case was "no other windows in the clipboard viewer chain",
which explains the 3rd party clipboard manager workaround detailed in the bug
description.
It also seems like SetClipboardViewer() does not clear the error state on
succcess. Calling SetLastError(0) before SetClipboardViewer() seems to solves
this issue.
Since we could not reproduce the bug on our env, the customer has verified on
several of their systems that a private build resolved the issue.
Diffstat (limited to 'client/glz_decode_tmpl.c')
0 files changed, 0 insertions, 0 deletions