Win32 clipboard error 1418 'Thread does not have a clipboard open': retry the read, skip the restore

Symptom

A dictation was lost with the error text Thread does not have a clipboard open. In pywin32 this arrives as pywintypes.error with winerror == 1418, which Windows defines as ERROR_CLIPBOARD_NOT_OPEN. The app puts text on the clipboard, sends Ctrl+V, and afterwards restores whatever was on the clipboard before, so it reads ("snapshots") every memory-backed clipboard format first.

What was observed

The app's changelog describes the failure as another application closing the clipboard while it was being read. A code comment on the close path adds that it was "seen while another application was rendering its data". The reading loop calls EnumClipboardFormats and GetClipboardData for each format; GetClipboardData makes the owning application render a format it had deferred, which is a plausible point for that application to touch the clipboard. That mechanism is an inference from the comment, not something the sources demonstrate.

The error text reads as if the calling thread never opened the clipboard. The source does not support that here: the clipboard was opened and closed by the same thread, and the error appeared on a call made after a successful open.

What was changed

All of this is in the app's paste module:

• Retry opening. OpenClipboard is retried up to 10 times with a 30 ms pause, because another application may hold the clipboard briefly. Any exception is retried, and the last attempt re-raises.
• Retry the snapshot on 1418 only. The whole read (open, enumerate, copy bytes, close) is attempted 3 times with a 50 ms pause when the error is 1418; any other error is raised immediately. If all three attempts fail the snapshot is None, meaning "contents unknown".
• Tolerate 1418 on close. CloseClipboard raising 1418 is logged as a warning and swallowed, because there is nothing left to close and raising would hide the error already propagating.
• No restore of unknown contents. When the snapshot is None, the paste still happens and the earlier clipboard contents are not put back; the skipped restore is logged. Restoring an empty or partial snapshot would erase what the user had copied.
• A failed restore is not a failed dictation. If putting the clipboard back raises after the paste has gone through, the exception is logged and the dictation is reported as successful.
• The same retry for a licence key. A menu action that reads a licence key from the clipboard also retries when another application is holding the clipboard.

Notes

• Clipboard formats that hold GDI or private handles (bitmap, palette, enhanced metafile and similar) cannot be copied as bytes; the snapshot skips them and the memory formats saved alongside them let Windows rebuild the common ones.
• The sources do not record how often the retry succeeded on the second or third attempt, or how often the fallback (paste without restore) was reached.
• Not verified: behaviour with clipboard-history managers or remote-desktop clipboard redirection, which also touch the clipboard.