Open Kuroonehalf opened 2 years ago
I believe it's that text parser, or Translator Aggregator in my case, failed to read the Clipboard. ITH/TA pair work fine, but Textractor/TA would skip some random lines.
I suspect Textractor monitoring the clipboard might be the culprit, since Translator Aggregator also does the same. They both are trying to access the same resource at the same time, but Textractor takes precedence. Upon testing, the missing text was properly copied to clipboard (try pasting on notepad) and I found Textractor clipboard capture got complete lines, but TA failed catching it. This behavior is similar to when I was running VM with host clipboard sharing feature turned on, while running TA on the host.
The ultimate root of the problem might lie in how Windows controls its clipboard however, but this problem exists for as long as I can remember.
Upon testing, the missing text was properly copied to clipboard (try pasting on notepad) and I found Textractor clipboard capture got complete lines, but TA failed catching it.
I did test pasting to a text file and the text was not there in clipboard. Actually, I have a program that keeps a history of stuff copied to the clipboard (Ditto), so I can see exactly where the copying stops.
You can modify the CopyToClipboard extension to repeat if it fails to open the clipboard. This is the code I've been using for a while with no issues:
bool ProcessSentence(std::wstring& sentence, SentenceInfo sentenceInfo)
{
if (sentenceInfo["current select"])
{
HWND TextractorWindow = FindWindowW(NULL, L"Textractor");
for (int loop = 0; loop < 10; loop++) {
if (OpenClipboard(TextractorWindow)) {
HGLOBAL hMem = GlobalAlloc(GMEM_MOVEABLE, (sentence.size() + 2) * sizeof(wchar_t));
memcpy(GlobalLock(hMem), sentence.c_str(), (sentence.size() + 2) * sizeof(wchar_t));
EmptyClipboard();
SetClipboardData(CF_UNICODETEXT, hMem);
GlobalUnlock(hMem);
CloseClipboard();
break;
}
std::this_thread::sleep_for(std::chrono::milliseconds(50));
}
}
return false;
I would not expect the issue to lie within Translator Aggregator (etc) as it should be periodically checking for changed clipboard text, so it shouldn't matter if it can't access the clipboard occasionally. CopyToClipboard, on the other hand, by default only tries once. Each program you have monitoring the clipboard will likely be a potential cause of clashes. Ditto itself may be the reason you're experiencing the issue - though as skyvory mentioned this is because of how the Windows Clipboard is set up.
As an aside, an Extensions settings menu would be appreciated to place settings like the number of retries (in this example) rather than each extension being forced to open its own window or hardcode things
x86 and x64 versions of the above code attached CopyToClipboard_WithRetry.zip
I'm also on windows 10 and using Ditto. I've seen this happen when I was also using Windows 10 Clipboard History feature (before moving to Ditto). I don't remember if it happens if I have Ditto/Clipboard History removed, might be something to look into.
@Niedzielan Thanks for this. I'm going to try it out.
EDIT: Tried it out, works great for me.
@Niedzielan Do you think you can open a PR with this fix for the original Copy to Clipboard
extension? I've been using it the past day and I haven't seen any issues with it.
CC: @Artikash
I've experienced this bug for a long time and thought it was actually related to the text parser I use, but today I found out that the issue lies with this extension. Seemingly with no rhyme or reason it will stop copying lines to clipboard, and eventually start working again. I haven't noticed any pattern to when it stops copying. It will happen randomly on just simple narration with no weird characters or anything.
Could you please look into it? Let me know if I can help you diagnose it. For reference, I'm on w10 and most of the time I'm running the x86 version of Textractor.