strange behavior using Clipboard variable Topic is solved

Get help with using AutoHotkey and its commands and hotkeys

strange behavior using Clipboard variable

20 Apr 2017, 18:09

Could someone tell me what am I missing please? I can't figure what's going on...
So, the custom function below unwantedy drops leading zero(s) in certain situations.

Code: Select all

ClipSend(vString:="",vWait:=0,vRest:=0) {
	If vString { ; is not empty
		Loop {
			If Clipboard ; is not empty
				Clipboard :=
			Else Break
		Clipboard := vString
		ClipWait, vWait
		if errorlevel
			MsgBox, Timed out
		Sleep vRest
		Send +{End}^v
	Else Send +{End}{Del}



When I load the script and execute ^numpad0 hotkey for the 1st time, I get 000111 (instead of expected 000110001),then on the 2nd hotkey execution I get 111.

Hotkey ^numpad1 on the other hand works as intented, as it always sends 0001010001...
Posts: 71
Joined: 24 Mar 2017, 18:14

Re: strange behavior using Clipboard variable

20 Apr 2017, 21:50

Don't have a good answer for you, but changing the assignment line to Clipboard := "" vString seems to work, and the send line to Send {shift down}{End}{shift up}^v seems to improve reliability.

Re: strange behavior using Clipboard variable

21 Apr 2017, 16:08

Thanks a lot, it works great!

So to me it seems that:
- in the beginning ahk consider 0...0(n) assignements as literal strings until it gets a "naked" number
- after that, 0...0(n) is treated as a number so "unneeded" leading zeros are dropped
- your workaround works by ensuring literal string behavior all the time
Posts: 2688
Joined: 08 Feb 2015, 20:55

Re: strange behavior using Clipboard variable  Topic is solved

21 Apr 2017, 17:10

see AutoTrim

You can add AutoTrim, Off to the auto-execute section of your otherwise unaltered script.
Or as the first line of your function might work as well, but that depends on where else you call the function from.

Re: strange behavior using Clipboard variable

23 Apr 2017, 12:48

Thanks but autotrim has no influence on zero:
Determines whether Var1 = %Var2% statements omit spaces and tabs from the beginning and end of Var2.

Instead here is a possible clue on v1 behavior (found in "v2-changes"):
Integer strings on v1 are always converted to pure/binary integers, even if that causes loss of data. For example, the following conversions are performed on v1, but on v2 the string is preserved:

"01" → 1
"+2" → 2
"0x3" → 3
" 4 " → 4
"9999999999999999999" → 9223372036854775807 (x64) or -1 (x86) due to the constraints of the integer key data type.

Return to “Ask For Help”

Who is online

Users browsing this forum: Bing [Bot], MagEpub and 64 guests