added currency rate fetching from poe.ninja

[aRTy42]

Thanks a lot. I'll look into it either later this evening or tomorrow and then release a new version.

[aRTy42]

The time comparison now - last > 1800 means older than 18 minutes, unless I misunderstood the ahk documentation. Am I mistaken, or why did you use such a short and not-round time span?

[4GForce]

1800 seconds == 30 minutes ??

[aRTy42]

https://autohotkey.com/docs/commands/FileSetTime.htm#YYYYMMDD

The timestamp is not in pure seconds. ...1758, 1759, 1800, 1801... are the adjacent ones.

[4GForce]

Well played, you were right. Using EnvSub is the way to go !

[Eruyome]

EnvSub may be the right way, I probably didn't use it because this

#SingleInstance force

last  := A_NowUTC
Sleep, 20000
now  := A_NowUTC

diff := now - last
MsgBox % diff  

returns the 20 seconds I use in the sleep. This doesn't work with higher delays though.

[aRTy42]

We don't need to change the method, just the number (if we want to). In the link it already says:

Note: Date-time values can be compared, added to, or subtracted from via EnvAdd and EnvSub. Also, it is best to not use greater-than or less-than to compare times unless they are both the same string length.

We do have the same string length, because we use the full format down to seconds.

I don't think currencies are shifting that quickly though, so both 18 or 30 minutes seems way too short to me. I'm considering something like 3 or 6 hours.

[4GForce]

String length wasn't the issue but using base arithmetic on time objects result in something like this 1m59s - 1m00s == 59s ( this is right ) 2m00s - 1m00s == 100s ( big bump for 1 second )

The 20 seconds example Eruyome posted works, unless you start the instance less than 20 seconds before the next minute.

In some other languages the arithmetic operators have overrides when used with time objects to do the proper calculations.

[aRTy42]

I know there is a jump. I pointed what format is used by ahk there. The old method is not reliable for Eruyome's example but would have worked for the use in the script, which was making sure the data does not get older than a set value. It would have updated an extra time if it was used shortly before and after a full hour or before and after midnight, but the function would not have failed. The major risk in comparing the timestamps is when the string length does not match because then you start comparing days with seconds or other nonsense.

The other solution is certainly cleaner in the sense that the script only updates exactly like defined.