Issue in 'saving last clipboard time'

[aviaryan]

From #103

Last clipboard write time should be saved by Clipjump to block successive clipboard captures which often lead to crashes.

The current method to get time is using A_TickCount. It fails when computer is not shutdown for days (in case of hibernate). https://autohotkey.com/boards/viewtopic.php?f=5&p=78007#p78007

So maybe, we can switch to using A_Now for time and EnvSub function for time difference.

[aviaryan]

Will close it after some testing

[Gabr-F]

Hi, I'm sorry I haven't shown up for the last months, I had some problems and after a while I just forgot.

I still won't be able to help much, but I'll probably manage to check out Clipjump every once in a while.

---

Anyway, I just tried the current version and I noticed that it doesn't work anymore on Windows XP (the software appears to work, but the clips don't get saved). I found out the culprit is the fix to this issue (in the commit 15db1d8c80426edf3cf2f79d2e5b9f1eb1c25457): the TickCount64 function was introduced in Windows Vista.

You could have good arguments to drop the support for Windows XP, but since for now it just takes fixing this to reinstate it, I think it is a worthwhile effort.

I see 3 ways to work-around the problem:

• check the windows version and use the old function if it's not at least Windows Vista.
• simply check the return of `DllCall("GetTickCount64"` , if it's blank the function is not supported and you can use A_TickCount in place of it
• **Do you actually really need** this 64 bit resolution??? For the problem at hand, wouldn't checking that `(A_TickCount - lastClipboardTime)` is >0 be reasonable enough?

  If I'm not mistaken this would only fail if you waited between two clipboard copies exactly from 49d,17h,2min,47s,298ms to 49d,17h,2min,47s,497ms.

  And if you actually did? Would making two successive clipboard captures distant 49d,17h,2min,47s etc. really risk to crash the computer??

  (btw, you could argue that one could put the system in hibernation/suspension for 49d etc. and turn it back on exactly within the 200ms interval; however, I think it's reasonable to assume that 200ms did pass between the moment you last made the clipboard copy and the moment the system got turned back on and you managed to press ctrl+c - an extremely fast system with a very fast user _might_ manage to do it within 200ms, but as we're probably not speaking of a life-threatening bug I think we might accept the risk... :stuck_out_tongue: )

[aviaryan]

Do you actually really need this 64 bit resolution??? For the problem at hand, wouldn't checking that (A_TickCount - lastClipboardTime) is >0 be reasonable enough?

The first time when I tried using A_TickCount, I got issues when trying to copy something to Clipjump after some days of hibernation. I am sure it was not 49+ days but after switching to GetTickCount64, I haven't faced any issues. So I went ahead with it. BTW, I still don't know what caused that no-copy issue stated before.

simply check the return of DllCall("GetTickCount64" , if it's blank the function is not supported and you can use A_TickCount in place of it

:+1:

[Gabr-F]

In any case, whatever function you use, it's a mistake not to ensure that the current tick count is greater than or equal to lastClipboradTime.

You can simply replace

if (timeDiff < 200){

with

if (timeDiff >= 0) and (timeDiff < 200){

With this you cut the time when it can go wrong from the entire period the function supports (49 days or half a million years) minus 200 ms to just 200 ms.

Arguably with the half a million years that TickCount64 gives you you could disregard this problem, but being careful about these things is still a good habit to take on.