On Mon Dec 26 03:09:17 2022 +0000, Zhiyi Zhang wrote:
Is a flush_events() call after edit window creation enough?
Unfortunately, no. I thought about it and tested it when I wrote the patch and it isn't always sufficient. Retested, still same result.
Adding some more traces about the messages I get (and messages sequence looks pretty consistent across runs): - after window creation: two WM_DWMNCRENDERINGCHANGED messages (wp=1, lp=0) (one for each created edit window) - after the first write to the clipboard: WM_TIMER (wp=1, lp=0) (message to window of class 'MSCTFIME UI' and title 'MSCTFIME' - none after the second write to the clipboard (and afterwards)
Note: in early testing of the cause of the failures, I noticed that adding some Sleep() calls after writing to the clipboard reduced the number of occurence of failures (without eradicating it).
A possible interpretation: the windows implementation doesn't paste clipboard content if the input message queue isn't empty. But I couldn't find doc/report by googling for this interpretation. Does it make sense to you?
(if interpretation is correct, then the patch reduces the likehood of having a msg in input queue, without fully eradicating it)