READ BINARY DATA FROM A FILE TO A VARIABLE
Since changes were made to FileRead, I needed to come up with a two-way compatible solution.
Code: Select all
;AHK v1
FileRead, vData, % "*c " vPath
;AHK v1/v2 two-way compatible
oFile := FileOpen(vPath, "r")
oFile.Pos := 0
oFile.RawRead(vData, oFile.Length)
oFile.Close()
;works on AHK v1.1* and AHK v2 (* with AHK v2 functions for AHK v1)
vPath1 := A_ScriptFullPath
vPath2 := A_AhkPath
vPath2 := vPath1
vSize1 := FileGetSize(vPath1)
vSize2 := FileGetSize(vPath2)
JEE_FileReadBin(vData1, vPath1)
JEE_FileReadBin(vData2, vPath2)
vRet := DllCall("ntdll\RtlCompareMemory", Ptr,&vData1, Ptr,&vData2, UPtr,vSize1<vSize2?vSize1:vSize2, UPtr)
MsgBox(vSize1 " " vSize2 " " vRet)
return
JEE_FileReadBin(ByRef vData, vPath)
{
oFile := FileOpen(vPath, "r")
oFile.Pos := 0
oFile.RawRead(vData, oFile.Length)
oFile.Close()
}
==================================================
STRSPLIT TO ARRAY (CUSTOM KEY NAMES CF. NUMERIC)
STRSPLIT TO VARIABLES
Dealing with variables instead of object keys can have its advantages.
- E.g. to deal with variables, rather than a mix of variables and object keys, which can be a little awkward to type when some have dots, and some have not.
- E.g. brevity, extreme case: variables: 'a' 'b' 'c' v. object keys: 'o.a' 'o.b' 'o.c'.
- If you are frequently/almost always going to convert the object keys to variables after using RegExMatch, this is an argument for maintaining the RegExMatch variable mode. Otherwise you convert the keys to variables afterwards, not so bad, although somewhat inconvenient.
- Neither StringSplit nor StrSplit output to named variables/keys, something that could be potentially useful.
- If you write a custom function, you can't specify to create variables local to where the function was called from, hence I couldn't make a version of RegExMatch to maintain the variable mode, and I couldn't create a function that works exactly like or similarly to StringSplit to create a pseudo-array (e.g. v1/v2/v3, vY/vM/vD), which can be useful for a small number of variables.
I'm posting this code, partly because if variable mode is removed from RegExMatch, then you need a bit of code to convert the object to variables.
Code: Select all
q:: ;split text to named variables/object keys
;split text to named variables
vText := "aaa,bbb,ccc", vList := "A,B,C"
oTemp := StrSplit(vText, ",")
Loop, Parse, vList, % ","
v%A_LoopField% := oTemp[A_Index]
oTemp := ""
MsgBox, % vA " " vB " " vC
;split text to named objects keys
vText := "aaa,bbb,ccc", vList := "A,B,C"
oTemp := StrSplit(vText, ",")
o := {}
Loop, Parse, vList, % ","
o[A_LoopField] := oTemp[A_Index]
oTemp := ""
MsgBox, % o.A " " o.B " " o.C
return
Code: Select all
w:: ;RegExMatch results from array to variables
vDate := 20060504030201
RegExMatch(vDate, "O)^(?P<Y>\d{4})(?P<M>\d{2})(?P<D>\d{2})", o)
MsgBox, % o.Y " " o.M " " o.D
vList := "Y,M,D"
Loop, Parse, vList, % ","
v%A_LoopField% := o[A_LoopField]
MsgBox, % vY " " vM " " vD
return
==================================================
AHK V1/V2 CONVERSION ISSUES UPDATE
- It will be easier to both convert and maintain my scripts, by using my JEE_FileReadBin function above, than via other routes. [EDIT: I mention this as an example of how exploring two-way compatibility can make one-way and two-way conversion easier. As it happens, I very much welcome the new support for binary variables in AHK v2, see the updated FileRead function and the new ClipboardAll function.]
- AHK v2 doesn't have a satisfactory way of dealing with the double quotes in command line parameters yet. I came up with a CdLn workaround function, and some other suggestions, here:
AHK v2 and strings - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=36833
- Anyhow, whatever is done regarding double quotes or Deref, I now have a fairly good workaround, my CdLn function, for the biggest string problem I've faced related to conversion. Note: this is not about compromising code appearance for the sake of compatibility, it is difficult to find a nice solution for this in AHK v2 full stop.
- I don't see any obstacles at present to two-way compatibility (although it's always possible), apart from Loop. This, if added to AHK v1/v2 would solve the problem, otherwise you go two-way compatible as far as you can:
AutoHotkey v2 alpha (UPDATES) - Page 2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=2120
Experimental: Loop, LoopFiles, LoopRead, LoopReg and LoopParse now support a function-like syntax, where the entire parameter list is enclosed in parentheses and all parameters are expressions. OTB is also supported.
It would be easy to jump on that and argue for it to solve the two-way compatibility question, but I'm finding the 3 choices quite tough:
- Loop XXX or LoopXXX [EDIT: LoopXXX looks better for LoopFiles/LoogReg/LoopRead, and OK for LoopParse]
- 'Cmd, Arg' or 'Cmd Arg', and Func(Arg) [EDIT: using commas looks better/cleaner, and is more consistent, because you have a separator character between function name and first parameter]
- allow function syntax version [EDIT: my one reservation was that it might look like a function definition, but having woken up the next day, it looks pretty good]
Code: Select all
LoopParse(vText, "`n", "`r")
LoopParse vText, "`n", "`r"
LoopParse, vText, "`n", "`r"
Loop (Parse, vText, "`n", "`r")
Loop Parse(vText, "`n", "`r")
Loop Parse vText, "`n", "`r"
Loop Parse, vText, "`n", "`r"
;what I would do in AHK v1
Loop, Parse, vText, `n, `r
{
MsgBox, % A_LoopField
}
;3 of the AHK v2 options
LoopParse(vText, "`n", "`r") ;[best]
{
MsgBox(A_LoopField)
}
LoopParse vText, "`n", "`r"
{
MsgBox(A_LoopField)
}
LoopParse, vText, "`n", "`r" ;not permissible in AHK v2 at present [best]
{
MsgBox(A_LoopField)
}
==================================================
[EDIT:] MOUSECLICK
The Click command as it is, is very confusing (cf. MsgBox's 'smart' parameters), so I would recommend:
Code: Select all
MouseClick, X, Y, Options
MouseDrag, X1, Y1, X2, Y2, Options
;or possibly:
MouseClick, Options, X, Y
MouseDrag, Options, X1, Y1, X2, Y2
Where Options is a space-separated list.
Possible names:
- Click/MouseClick (I would merge the two commands, and keep one name).
- MouseClickDrag (or possibly MouseDrag) (not great: ClickDrag, Drag).
- MouseMove.
- I would keep the name 'Click' for use with Send/SendInput.
'MouseDrag' is logical, although 'MouseClickDrag' has a certain elegance, and since (a) hotstrings, (b) lack of frequent use, I don't mind the longer 'MouseClick'/'MouseClickDrag' names. Choices. [EDIT: I did also consider 'Drag' by itself, but I don't feel inclined towards it. 'MouseDrag' is not bad/not good. I'm not sure whether 'ClickDrag' is an oxymoron or not.]
[EDIT:] Potentially a mini one-parameter format for Send {Click} could be: e.g. to drag the mouse: Send {Click x10 y10 xd10 yd20}, d for destination (or drag), e.g. to double-click the right mouse button: Send {Click x10 y10 r dc}, 'dc' or perhaps better 'c2' for double-click, perhaps 's10' for speed or 'd10' for a 10-millisecond delay, 'rel' for relative or 'cmr' for CoordMode Relative, 'u'/'d' for up/down (hold/release).
[EDIT:] dx10 dy10 for drag destination coordinates would be easier to parse, and are possibly easier to remember, and look better. E.g. {Click x10 y10 dx10 dy20} {Click x10 y10 r c2 rel}.