Have a simple setup with Ditto/latest beta: 3.21.137 on Windows 7 pro sp1. running side by side clipbrd.exe (Windows xp clipboard viewer) just to compare.
Now launch Moba Xterm, and ssh (with X11, and copy/paste enabled) into another machine, and open an Xterm on the Windows machine (this functionality is buildin in Moba Xterm), now you get an Xterm window on the remote machine, displayed on the Windows 7 machine.
On that window, clicking anything, selects it (linux), and in clipbrd.exe that selection can be seen right away, however, nothing is picked up in Ditto.
As a result, paste on the LOCAL machine works, but paste on a REMOTE ditto connected machine, does not work.
The question, why doesn't ditto pickup this selection?
Thankzzz :)
Stormy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there an option in ditto to tell it to 'duplicate' whatever is in Windows clipboard? or maybe it does that, but somehow misses the notification that the clipboard was actually modified?
Stormy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After Ditto does not save the clip what happens in Ditto if you manually load from the clipboard, right click on task bar icon - save current clipboad. Does this work?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By default Ditto waits to pull the data by 100ms after it is notified. Proably to fast in this case. Try a larger value, 500ms to a couple seconds. Ditto needs to be restarted after adding the setting. Value is in milliseconds
Oh dear... well, ping to remote machine is about 230ms. Tried 1000ms at first it worked OK for a bit, later had to switch it to 1500ms (dropping even to 1300ms didnot work). The crazy part is that all these tries the Windows (native) clipboard viewer always shows the right buffer.
Is there any chance ditto can "internally retry" until it sees new data? considering it was notified, then it should assume that new data exists, and it can "re-attempt" for say "x" ms to find new data..
I was sure there's some "atomic" way to be notified/copy, this polling sleep seems not 100% reliable, and looking back, it might have impacted my other tests using VNC, I may try higher values there, drawback of course is u have to wait for 1.5 seconds for the copy to take effect, and a it more to propagate to all other connected clipboards.
Thanks for this tip.
Stormy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OR? is this some MOBAXterm "wrongdoing" by notifying "ditto" too soon? before copy is completed? Just not sure how this works, I would assume Windows OS would notify ditto.. so, not sure why data is not in buffer after notification.. I would assume no1 would notify before all data is in position, but then again, I may be assuming too much :) :)
Stormy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you enable logging (https://sourceforge.net/p/ditto-cp/wiki/Debug%20Logging/) and go back to the default timeout and copy a few items, then upload the debug. I'll look at the debug and try to handle auto retry in this case.
scott
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Forgot there was already a retry delay. This defaults to 200ms, I should make that bigger by default. The value is milliseconds to sleep before retrying.
OK, thanks much, generally, personally, i prefer lower timeouts and more retries, running with larger timeouts (like 2000) means that for 2 seconds the app is not doing anything, so it is a lot less responsive, compared to say, 5 retries each 400ms, sure, wastes a bit cpu, but allows for better tuning..
anyways, set: ProcessDrawClipboardDelay=300, and then retry delay must be 1000 or higher for it to pickup the copy from these windows.. is there a parameter deciding how many TIMES to retry? then one could go with 300ms and 5 retries maybe? yes, i did see retries in the logs sent to you :)
Thanks for the support and improvements.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have a simple setup with Ditto/latest beta: 3.21.137 on Windows 7 pro sp1. running side by side clipbrd.exe (Windows xp clipboard viewer) just to compare.
Now launch Moba Xterm, and ssh (with X11, and copy/paste enabled) into another machine, and open an Xterm on the Windows machine (this functionality is buildin in Moba Xterm), now you get an Xterm window on the remote machine, displayed on the Windows 7 machine.
On that window, clicking anything, selects it (linux), and in clipbrd.exe that selection can be seen right away, however, nothing is picked up in Ditto.
As a result, paste on the LOCAL machine works, but paste on a REMOTE ditto connected machine, does not work.
The question, why doesn't ditto pickup this selection?
Thankzzz :)
Stormy.
Tried with older MobaXterm 8.6, and newer 9.4, same issue (can download from here: http://mobaxterm.mobatek.net/download-home-edition.html)
Is there an option in ditto to tell it to 'duplicate' whatever is in Windows clipboard? or maybe it does that, but somehow misses the notification that the clipboard was actually modified?
Stormy.
After Ditto does not save the clip what happens in Ditto if you manually load from the clipboard, right click on task bar icon - save current clipboad. Does this work?
Amazing! Yes, that adds the text to the local ditto window, and broadcasts to all connected machines..
By default Ditto waits to pull the data by 100ms after it is notified. Proably to fast in this case. Try a larger value, 500ms to a couple seconds. Ditto needs to be restarted after adding the setting. Value is in milliseconds
[HKEY_CURRENT_USER\Software\Ditto]
"ProcessDrawClipboardDelay"=dword:00002000
Ok!! that's it!
Oh dear... well, ping to remote machine is about 230ms. Tried 1000ms at first it worked OK for a bit, later had to switch it to 1500ms (dropping even to 1300ms didnot work). The crazy part is that all these tries the Windows (native) clipboard viewer always shows the right buffer.
Is there any chance ditto can "internally retry" until it sees new data? considering it was notified, then it should assume that new data exists, and it can "re-attempt" for say "x" ms to find new data..
I was sure there's some "atomic" way to be notified/copy, this polling sleep seems not 100% reliable, and looking back, it might have impacted my other tests using VNC, I may try higher values there, drawback of course is u have to wait for 1.5 seconds for the copy to take effect, and a it more to propagate to all other connected clipboards.
Thanks for this tip.
Stormy
OR? is this some MOBAXterm "wrongdoing" by notifying "ditto" too soon? before copy is completed? Just not sure how this works, I would assume Windows OS would notify ditto.. so, not sure why data is not in buffer after notification.. I would assume no1 would notify before all data is in position, but then again, I may be assuming too much :) :)
Stormy
Can you enable logging (https://sourceforge.net/p/ditto-cp/wiki/Debug%20Logging/) and go back to the default timeout and copy a few items, then upload the debug. I'll look at the debug and try to handle auto retry in this case.
scott
Forgot there was already a retry delay. This defaults to 200ms, I should make that bigger by default. The value is milliseconds to sleep before retrying.
[HKEY_CURRENT_USER\Software\Ditto]
"NoFormatsRetryDelay"=dword:00002000
scott
OK, thanks much, generally, personally, i prefer lower timeouts and more retries, running with larger timeouts (like 2000) means that for 2 seconds the app is not doing anything, so it is a lot less responsive, compared to say, 5 retries each 400ms, sure, wastes a bit cpu, but allows for better tuning..
anyways, set: ProcessDrawClipboardDelay=300, and then retry delay must be 1000 or higher for it to pickup the copy from these windows.. is there a parameter deciding how many TIMES to retry? then one could go with 300ms and 5 retries maybe? yes, i did see retries in the logs sent to you :)
Thanks for the support and improvements.