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 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1886#note_20155