On Mon Dec 26 09:00:52 2022 +0000, eric pouech wrote:
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)
actually, this doesn't look to be the case. After several different testings methods, adding some busy-loop after closing the clipboard makes the test pass (without any event flushing involved). it looks like the data in the clipboard are not immediately available after CloseClipboard() returns... I don't like the Sleep(xx) in-between, and couldn't think of a way to synchronize. so replacing SendMessageA(h???, WM_PASTE, 0, 0); with something like ``` for (retry = 0; retry < 3; retry++) { SendMessageA(h???, WM_PASTE, 0, 0); if (SendMessageA(h???, WM_GETTEXTLENGTH, 0, 0)) break; Sleep(20); } ``` could do the trick