A_ variables

Discuss the future of the AutoHotkey language
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

A_ variables

25 Dec 2017, 18:52

I searched through all of my posts, and collected notes regarding 'A_' variables.

I have proposed variable names for each idea, but any of these could be changed if desired.

I have split the proposals into two, with the less pressing ones in the second half.

As part of researching this, I have updated this link:
list of every command/function/variable from across all versions - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 42#p131642

RECENTLY FIXED
A_CaretX/A_CaretY: now CaretGetPos in AHK v2 (but remains as is in AHK v1).
A_Args: now available in both AHK v1 and v2.

[basis of code for a custom CaretGetPos backport]
convert coordinates between Client/Screen/Window modes - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=38472

CONTROLS: COORDINATES
A_CoordModeControl: to specify window/client coordinates for ControlXXX functions.

v2-changes
https://autohotkey.com/v2/v2-changes.htm
ControlMove, ControlGetPos and ControlClick now use client coordinates (like GuiControl) instead of window coordinates.
[basis of code for custom ControlXXX backports: JEE_ControlGetPosClient]
FileSelectFile, add controls to the Open/Save As dialog - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=29934
[also:]
convert coordinates between Client/Screen/Window modes - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=38472

MOUSE
A_MouseSwapMode(/A_MouseButtonsSwapped/A_MouseButtonSwap/A_MouseSwapButtons): to determine how to handle {Click}/{Click right} etc.

SCRIPT PID
A_ScriptPID

This is possible:
vScriptPID := DllCall("kernel32\GetCurrentProcessId", UInt)
- I have numerous functions, where DllCall is used to get the PID as a static variable. Referring to a built-in variable would be preferable.
GUIs via DllCall: get/set internal/external control text - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=40514
- Also, when you execute code dynamically, e.g. for use with dll injection, or ExecScript, retrieving the PID like this clutters otherwise straightforward code.
- If an A_ScriptPID variable isn't available, then a custom ScriptGetPID function could be used, but this adds an annoying dependency to functions that are otherwise stand-alone.
- Anyway, the arguments for this are subtle, but overall, I think it is worthwhile. Also, I would use this variable far more frequently than many other variables.

FILES AND FOLDERS
summary of existing variables:
A_AhkDir [invalid], A_AhkPath, A_AhkName [invalid]
A_LoopFileDir, A_LoopFileFullPath, A_LoopFileName
A_ScriptDir, A_ScriptFullPath, A_ScriptName
A_WorkingDir
A_InitialWorkingDir [AHK v2 only]

- In my opinion, keeping A_ScriptName constant would be preferable.
- I would rather have a variable such as A_DlgTitle(/A_GuiTitle/A_DefaultTitle) to specify the default MsgBox/InputBox title.
- I would like my scripts to both have an A_DlgTitle variable available, but continue to be able to depend on A_ScriptName to reliably specify the name (including extension) of the script.
- Also, adding A_AhkDir would make the variables more consistent, reducing cognitive conflict:
cf. the capitalisation of 'Lock'
Suggestions on documentation improvements - Page 15 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 00#p189900
cf. 'Control, WinTitle, WinText, ExcludeTitle, ExcludeText'
Parameter order - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=30439

- It would also be worth backporting A_ComSpec and probably A_InitialWorkingDir.

FILES AND FOLDERS: #INCLUDE
Wish List 2.0 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 13&t=36789
>>> #Include: support more 'A_' variables
- support: A_Desktop, A_AhkPath, A_UserName, possibly 'A_Args##' [EDIT: this has been implemented except for A_Args##]
- A_AhkPath could be especially useful, as each exe in a folder could have its own folder or files e.g. 'AutoHotkeyU64 1.1.26.01.exe Lib' 'AutoHotkeyU64 1.1.26.01.exe.ahk'
- a lot of things 'can' be done with the #Include directive, but are unnecessarily and sometimes fiendishly complicated to do, and not newbie friendly
- other ideas would include: #IncludeIfArgContains (i.e. include a file if the nth command line parameter contains a certain string)
- Another idea would be an /inc switch. Although having both solutions available would be best, and worthwhile in my opinion.
- I see making A_AhkPath available in this way, as an excellent way to have libraries that are unique to particular AHK exes. Is there any better/simpler solution?
- I recently moved the AHK exes out of C:\Program Files\AutoHotkey, since the folder causes admin nags, increasing the utility of variables such as A_Desktop and A_UserName.
- A_Desktop is also useful for specifying paths that are relative to C:\Users\%username% (or C:\Documents and Settings\%username%).
- E.g. of a workaround. This works but the #Include is allowed to fail which can be undesirable.

Code: Select all

#Include *i %A_AppData%\..\..\Desktop\MyScript.ahk
#Include *i %A_AppData%\..\Desktop\MyScript.ahk
EDIT PATH AND TRAY ICONS
A_EditTarget (or A_EditPath/A_EditCommand/A_EditOpenWith): Since changing the path of the program that edits scripts when Edit is used, depends on editing the registry, which isn't always accessible, it would be advantageous to be able to specify that path internally, via a variable. The variable could contain command line text including %1, just like what would appear in the registry key. E.g. "C:\Program Files\Windows NT\Accessories\wordpad.exe" "%1"

To specify paths/hIcons for the 4 systray icons:
A_IconFile (already exists)
A_IconFileP
A_IconFileS
A_IconFilePS
(where P and S stand for paused/suspended)

SORT
A_SortMode/A_SortStable: To specify stable/unstable sort.
- This could also be a parameter option in the Sort command, but most people who would want stable sort for the Sort command, would want it on by default, and so would want to blanket set all instances of the Sort command to use stable sort.
- Btw I believe that many (most?) users don't know what the difference is between stable/unstable sort, and would expect stable sort to be the default. Unstable sort is currently the default.
- Unstable sort: when two items are considered equal by the function, they can be rearranged. Stable sort: when two items are considered equal by the function, the earlier item remains earlier.

==================================================

MINOR: SPECIAL CHARACTERS: A_SPACE / A_TAB
Potentially useful variables, following a move to function syntax in AHK v2, to aid readability in certain cases:
A_Comma
A_DQ(/A_DQuote)
A_LP(/A_LParen)
A_RP(/A_RParen)
A_Sp (or Sp/StrRept functions, to repeat spaces)
A_SQ(/A_SQuote)

MINOR: DATES
I believe that the following are needed frequently enough to potentially deserve special variables:
A_NowMSec/A_NowMSecUTC: or a function to get both A_Now and A_MSec separately but in sync. It is never reliable to combine the use of separate variables to form a datestamp. E.g. New Year's Eve: you get the month, then the year, but the year changed as you did this. [EDIT: or a DateGet function as suggested in a post below.]
A_Today: the first 8 characters of A_Now.

MINOR: FILES AND FOLDERS:
There is potential value in having the following variables:
A_Recent(/A_RecentItems): the My Recent Documents/Recent Items folder.

A_AhkNameNoExt (and A_AhkDir/A_AhkName): for use with #Include (e.g. %A_AhkDir%\%A_AhkNameNoExt% Options.txt).
A_LoopFileNameNoExt: commonly useful.
A_ScriptNameNoExt: for use with MsgBox/InputBox/GUI titles and for use with #Include (e.g. %A_ScriptDir%\%A_ScriptNameNoExt% Options.txt).

MINOR: AHK V2 MODE FOR AHK V1
A 'SetAhkV2Mode' function or directive, would make certain things work as they do in AHK v2:
E.g. A_OSVersion (and also: InStr/SubStr/RegExMatch/RegExReplace, Loop).

MINOR: TIME IDLE
A_TimeIdlePhysical: An option to ignore mouse movements, i.e. the value is not reset to 0 by mouse movements. [EDIT: This has been implemented as A_TimeIdleKeyboard and A_TimeIdleMouse.]
A workaround:
A_TimeIdlePhysical to detect any input but not mouse movement? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 50#p170250

MINOR: LISTLINES
A_ListLines: To know whether it is on/off, to only record information for lines where a suspected bug will occur/to turn it off temporarily for loops. [EDIT: This has been implemented.]

MINOR: HOTKEYS
Variables such as these could potentially have merit:
A_ThisHotkeyHwnd(/A_ThisHwnd): active window when the hotkey was triggered.
A_ThisHotkeyIfWin(/A_ThisIfWinCriteria): #IfWin criteria when the hotkey was triggered.
A_ThisHotkeyNum(/A_ThisHotkeyIndex/A_HotkeyCount): a count of how many hotkeys have been triggered since the script loaded.
A_TimeOfPriorHotkey (cf. A_TimeSincePriorHotkey): the absolute time the hotkey was triggered, rather than the relative time.

Alternatively I could restructure the entire way that I define hotkeys in my script, to obtain such information via custom functions:
log hotkeys, get extended hotkey info, interact with the *right* window (Hotkey command with FunctionObject example) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=29560
Last edited by jeeswg on 17 Feb 2018, 10:48, edited 3 times in total.
Helgef
Posts: 3221
Joined: 17 Jul 2016, 01:02
Contact:

Re: A_ variables

27 Dec 2017, 15:01

Hello jeeswg, I hope you have had a merry christmas :wave:. Brief comments,
CaretGetPos
:thumbup:
A_ScriptPID
See [url=https://lexikos.github.io/v2/docs/commands/Process.htm#Exist]processExist[/url]()
If the PID-or-Name parameter is blank, the script's own PID is retrieved.

DATES
Maybe something like getTime() which returns an associative array containing something like this SYSTEMTIME.
SetAhkV2Mode
I think that is pointless, you can just use v2 instead :thumbup: .
MINOR: HOTKEYS
All these ideas tells me we need to have hotkey objects... ;)

Cheers.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

27 Dec 2017, 16:59

Hello Helgef, I hope you have had a merry Christmas too :wave:. Brief comments,
- CaretGetPos. Yes, you really seemed concerned about A_CaretX/A_CaretY.
- A_ScriptPID. Good point about ProcessExist(), although that's not currently in AHK v1. A_ScriptPID looks good, and is consistent with A_ScriptHwnd.
- SetAhkV2Mode. I see this partly as fixing bugs: InStr/SubStr should have used a negative offset, and A_OSVersion should have used numbers, from the beginning, in my opinion.
- SetAhkV2Mode continued. It could also set #NoEnv and SetBatchLines, -1. And it could also allow `" to be used instead of "" cf. #EscapeChar.
- SetAhkV2Mode continued again. I can recreate InStr/SubStr, keeping the function names, by using StringGetPos/StringMid (and setting the AHK v1/v2 mode based on a global variable). But to fix RegExMatch/RegExReplace, you would need to refer to the original functions, and so you can't keep the function names. One alternative: I am using 4 functions with the same names as the originals but with a 'JEE_' prefix (e.g. JEE_SubStr) that give the AHK v2 functionality in both AHK v1 and v2, I only use them whenever AHK v1/v2 differ (negative offsets/objects).
- SetAhkV2Mode revisited. If these little fixes save you from having to create two versions of your four dozen AHK libraries, it could be worth it! A fix for Loop/double quotes would be the most important.
- Btw, since I started using AHK, I've always wondered whether something with this effect: try global A_XXX := could be possible. To backport 'A_' variables, without crashing newer scripts.
- A_NowMSec. Interesting idea re. GetTime(). I might call it GetDate(). [EDIT: Actually, DateGet() would be more consistent with my function libraries.] E.g. I think that FormatTime should have been called 'FormatDate', and DateAdd/DateDiff use 'Date', and I used JEE_DTPGetDate, not 'JEE_DTPGetTime', as I thought it would be clearer.

Code: Select all

oDate := DateGet()
vOutput := oDate.Now " " oDate.MSec " " oDate.WDay
. "`r`n" A_Now " " A_MSec " " A_WDay
. "`r`n" RegExReplace(oDate.Now, "(....)(..)(..)(..)(..)(..)", "$1-$2-$3 $4:$5:$6") "." oDate.MSec " " oDate.WDay
MsgBox, % vOutput

DateGet(vOpt:="")
{
	VarSetCapacity(SYSTEMTIME, 16, 0)
	if (vOpt = "UTC")
		DllCall("kernel32\GetSystemTime", Ptr,&SYSTEMTIME)
	else
		DllCall("kernel32\GetLocalTime", Ptr,&SYSTEMTIME)
	oDate := {}
	oDate.Year := Format("{:04}", NumGet(&SYSTEMTIME, 0, "UShort")) ;wYear
	oDate.Month := Format("{:02}", NumGet(&SYSTEMTIME, 2, "UShort")) ;wMonth
	oDate.WDay := 1+NumGet(&SYSTEMTIME, 4, "UShort") ;wDayOfWeek
	oDate.Day := Format("{:02}", NumGet(&SYSTEMTIME, 6, "UShort")) ;wDay
	oDate.Hour := Format("{:02}", NumGet(&SYSTEMTIME, 8, "UShort")) ;wHour
	oDate.Min := Format("{:02}", NumGet(&SYSTEMTIME, 10, "UShort")) ;wMinute
	oDate.Sec := Format("{:02}", NumGet(&SYSTEMTIME, 12, "UShort")) ;wSecond
	oDate.MSec := Format("{:03}", NumGet(&SYSTEMTIME, 14, "UShort")) ;wMilliseconds
	oDate.Now := oDate.Year oDate.Month oDate.Day oDate.Hour oDate.Min oDate.Sec
	oDate.Today := oDate.Year oDate.Month oDate.Day
	return oDate
}
- Btw what is the best way to get the hour difference between UTC/local, if you get the local/UTC timestamps and compare, the time zone might have changed (daylight-saving time might have started/ended) while you were getting the timestamps.
Last edited by jeeswg on 07 Jan 2018, 15:00, edited 2 times in total.
coffee
Posts: 76
Joined: 01 Apr 2017, 07:55

Re: A_ variables

27 Dec 2017, 19:16

- A_ScriptPID. Good point about ProcessExist(), although that's not currently in AHK v1. A_ScriptPID looks good, and is consistent with A_ScriptHwnd.
How so? process, exist behaves the same way. If you don't specify a process, it sets errorlevel to the script's pid, you can just return errorlevel with a wrapper function.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

27 Dec 2017, 19:43

vScriptPID := DllCall("kernel32\GetCurrentProcessId", UInt)
- Using DllCall (AHK v1/v2 two-way compatible), what I'm doing now, is preferable to using the Process command which can only be used in AHK v1.
- Note: when I use this with dynamic code, for use in two-way compatible libraries, I have to store the code in a variable and replace the double quotes with Chr(34), which adds to the awkwardness and lack of readability.
- Anyway, that is simply more background info, and not intended as further justification. The case for A_ScriptPID is subtle. A further valid argument would be to say that A_ScriptPID is more readable/self-explanatory and less cryptic than ProcessExist().
Helgef
Posts: 3221
Joined: 17 Jul 2016, 01:02
Contact:

Re: A_ variables

28 Dec 2017, 18:43

Hello, my christmas was very joyful :xmas:
A_ScriptPID looks good
Sure ;)
I see this partly as fixing bugs
I wouldn't call that fixing bugs, but I agree the v2 versions are preferable.
SetAhkV2Mode revisited. If these little fixes save you from having to create two versions of your four dozen AHK libraries, it could be worth it!
First I am not competent enough to agree on this being little fixes, I have a hard time imagining anyone wanting to implement and document it though. Further, I do not think I grasp the concept, could you please hold my hand and make an explicit example, preferably short, on how to use this?

Cheers.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

28 Dec 2017, 21:17

- I'm glad your Christmas was very joyful.
- Thanks for showing an interest in SetAhkV2Mode. If even you struggle a bit with the ideas, i.e. what they mean isn't immediately obvious to people, then perhaps I'd better explain them more fully, 'show me' is better than 'tell me'.

Basically re. two-way compatibility, this is what happens:
To run AHK v2 scripts in AHK v1:
- you start with an AHK v2 script written in such a way that it can easily be converted to AHK v1
- changes to control flow statements (e.g. Loop)/directives/syntax (e.g. "" v. `"): potentially a go-between script could convert certain things in an AHK v2 script before you run it in AHK v1
- changes to variables: you could use custom functions to give you the same content
- changes to functions (that were functions in AHK v1): you could recreate the functions but give them a different name (or for InStr/SubStr, you can keep the names but use StringGetPos/StringMid inside the function definitions)
- new AHK v2 functions (that were commands in AHK v1): use the forwards compatibility library for AHK v1
- new AHK v2 functions (new to AHK v2): use the forwards compatibility library for AHK v1
- GUIs: someone would have to write a GUI forwards compatibility library for AHK v1 (it probably won't be me, I use my own custom two-way compatible GUI functions)

SetAhkV2Mode variable/directive set to on (for AHK v1 only):
- (these 5 settings might be granular)
- (these settings could potentially be turned on/off while the script is running)
- InStr/SubStr behaves like on AHK v2
- RegExMatch/RegExReplace behaves like on AHK v2
- A_OSVersion behaves like on AHK v2
- [EDIT:] Also, default settings: SetTitleMatchMode is set to 2 ('contains') by default.
- [EDIT:] Perhaps #MaxMem needs to be set to 4095 (the largest possible number).
- [EDIT:] AutoTrim should be irrelevant to an AHK v1 script that only uses AHK v2 syntax, however, perhaps there is some benefit to SetAhkV2Mode setting AutoTrim to off.

SetAhkV2Mode directive set to on (for AHK v1 only):
- (these 4 settings might be granular)
- #NoEnv is on
- SetBatchLines is set to -1
- `" converted to "" before script launches
- Loop function-style parameters converted to command-style parameters before script launches
- [EDIT:] Also, default settings: #SingleInstance is set to force by default.

- Examples of provisional InStr/SubStr functions for AHK v1, that can be made to behave like AHK v1/v2 based on a variable AX_SetAhkV2Mode. You would call them simply InStr or SubStr (they have a ZJEE_ prefix below).
- Examples of provisional InStr/SubStr/RegExMatch/RegExReplace functions (with a JEE_ prefix) for AHK v1/v2, that behave like the AHK v2 functions.
- An OSVersion function.
- All of the functions may potentially have some minor flaws or differences to the originals.

Code: Select all

q:: ;test SubStr
vText := "abcdef"
vPos := 3
vPos := -3
vLen := 3
vLen := ""
vLen := -3
vOutput := SubStr(vText, vPos, vLen) ;AHK v1
vOutput .= "`r`n" JEE_SubStr(vText, vPos, vLen) ;AHK v2
AX_SetAhkV2Mode := 0
vOutput .= "`r`n" ZJEE_SubStr(vText, vPos, vLen) ;AHK v1
AX_SetAhkV2Mode := 1
vOutput .= "`r`n" ZJEE_SubStr(vText, vPos, vLen) ;AHK v2
MsgBox, % vText "`r`n" vPos " " vLen "`r`n=====`r`n" vOutput "`r`n====="
return

;==================================================

w:: ;test InStr
vText := "abcABCabcABC"
vNeedle := "a"
vNeedle := "A"
vCaseSen := 0
vCaseSen := 1
vPos := 1
vPos := 7
vOcc := 1
vOcc := 2
vOcc := -1
vOcc := -2
vOutput := InStr(vText, vNeedle, vCaseSen, vPos, vOcc) ;AHK v1
vOutput .= "`r`n" JEE_InStr(vText, vNeedle, vCaseSen, vPos, vOcc) ;AHK v2
AX_SetAhkV2Mode := 0
vOutput .= "`r`n" ZJEE_InStr(vText, vNeedle, vCaseSen, vPos, vOcc) ;AHK v1
AX_SetAhkV2Mode := 1
vOutput .= "`r`n" ZJEE_InStr(vText, vNeedle, vCaseSen, vPos, vOcc) ;AHK v2
MsgBox, % vText "`r`n" vPos " " vLen "`r`n=====`r`n" vOutput "`r`n====="
return

;==================================================

;provisional (not guaranteed to work 100% correctly)
;for AHK v1 only:
;works like AHK v1 if AX_SetAhkV2Mode = 0
;works like AHK v2 if AX_SetAhkV2Mode = 1
;the idea is to rename this to InStr, without loss of functionality,
;AX_SetAhkV2Mode would determine whether it behaved like AHK v1/v2
ZJEE_InStr(ByRef vText, vNeedle, vCaseSen:=0, vPos:=1, vOcc:=1)
{
	global AX_SetAhkV2Mode
	if AX_SetAhkV2Mode && (vPos = 0)
		return
	if AX_SetAhkV2Mode && (vPos <= -1)
		vPos++
	vSCS := A_StringCaseSense
	StringCaseSense, % vCaseSen ? "On" : "Off"
	if (vPos <= 0)
		vOcc := "R" vOcc
	else
		vOcc := "L" vOcc
	StringGetPos, vRet, vText, % vNeedle, % vOcc, % vPos-1
	StringCaseSense, % vSCS
	return 1+vRet
}

;==================================================

;provisional (not guaranteed to work 100% correctly)
;works like AHK v1 if AX_SetAhkV2Mode = 0
;works like AHK v2 if AX_SetAhkV2Mode = 1
;the idea is to rename this to SubStr, without loss of functionality,
;AX_SetAhkV2Mode would determine whether it behaved like AHK v1/v2
ZJEE_SubStr(ByRef vText, vPos, vLen:="")
{
	global AX_SetAhkV2Mode
	if AX_SetAhkV2Mode && (vPos = 0)
		return
	if AX_SetAhkV2Mode && (vPos <= -1)
		vPos++
	if (vPos < -StrLen(vText))
		vPos := 1
	else if (vPos < 0)
		vPos := StrLen(vText)+vPos
	if (vLen = "")
		vLen := StrLen(vText)
	if (vLen < 0)
	{
		StringMid, vRet, vText, % vPos
		vLen := StrLen(vRet) + vLen
		if (vLen >= 0)
			StringMid, vRet, vRet, 1, % vLen
	}
	else
		StringMid, vRet, vText, % vPos, % vLen
	return vRet
}

;==================================================

;works like InStr (AHK v2) (on AHK v1/v2)
JEE_InStr(ByRef vText, vNeedle, vCaseSen:=0, vPos:=1, vOcc:=1)
{
	static vIsV1 := !!InStr(1,1,1,0)
	if (vPos = 0)
		return
	if vIsV1 && (vPos <= -1)
		vPos++
	return InStr(vText, vNeedle, vCaseSen, vPos, vOcc)
}

;==================================================

;works like SubStr (AHK v2) (on AHK v1/v2)
JEE_SubStr(ByRef vText, vPos, vLen:="")
{
	static vIsV1 := !!SubStr(1,0)
	if (vPos = 0)
		return
	if vIsV1 && (vPos <= -1)
		vPos++
	if (vLen = "")
		return SubStr(vText, vPos)
	return SubStr(vText, vPos, vLen)
}

;==================================================

;works like RegExMatch (AHK v2) (on AHK v1/v2)
JEE_RegExMatch(ByRef vText, vNeedle, ByRef oArray:="", vPos:=1)
{
	;we're not interested in the return value, but we need it to get RegExMatch to take place
	static vRet := RegExMatch("","",o), vIsV1 := !IsObject(o)
	if !vIsV1
		return RegExMatch(vText, vNeedle, oArray, vPos)
	if (vPos = 0)
		return
	if vIsV1 && (vPos <= -1)
		vPos++
	if RegExMatch(vNeedle, "^[A-Za-z`a`n`r `t]*\)")
		vNeedle := "O" vNeedle
	else
		vNeedle := "O)" vNeedle
	return RegExMatch(vText, vNeedle, oArray, vPos)
}

;==================================================

;works like RegExReplace (AHK v2) (on AHK v1/v2)
JEE_RegExReplace(ByRef vText, vNeedle, vReplaceText, ByRef vCount, vLimit:=-1, vPos:=1)
{
	static vIsV1 := !RegExReplace(10, 1,,,, -1)
	if (vPos = 0)
		return
	if vIsV1 && (vPos <= -1)
		vPos++
	return RegExReplace(vText, vNeedle, vReplaceText, vCount, vLimit, vPos)
}

;==================================================

JEE_OSVersion()
{
	vVersion := DllCall("kernel32\GetVersion", UInt)
	return Format("{}.{}.{:04}", vVersion & 0xFF, (vVersion >> 8) & 0xFF, (vVersion >> 16) & 0xFFFF)
}

;==================================================
- I may need to fix the RegExMatch function to handle line breaks differently (the behaviour has changed in AHK v2).
- A_Args was backported to AHK v1 which is a big help re. two-way compatibility.
- Also, force-local has been added to AHK v1/v2, which is also a big help re. two-way compatibility because of issues with declaring variables in functions that are/aren't special AHK variables in AHK v1/v2 e.g. ComSpec/A_ComSpec.
Helgef
Posts: 3221
Joined: 17 Jul 2016, 01:02
Contact:

Re: A_ variables

29 Dec 2017, 13:19

Hello, thanks for your thorough answer.
Please correct me, the idea is that you write new scripts in v2 style, but when you want to use your old v1 libraries, you set SetAhkV2Mode on and then everything works, given that you have your commands as functions lib?
you start with an AHK v2 script written in such a way that it can easily be converted to AHK v1
This is vauge, and its meaning could change with every update. I do not want to code like that, it is defeating the purpose of using v2 for me.

I will digest the information, then reread and comment further if I need. Cheers.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

29 Dec 2017, 15:13

- Sorry, haven't read your post, still suffering from trying to recreate InStr/SubStr using StringGetPos/StringMid.
- (I knew I would have to do it at some point, to demonstrate the principle.) (I did read your post.)
- Btw SubStr doesn't handle a blank as the Length parameter, my functions do, and I think this behaviour would be preferable. (A blank string would give the same effect as omitting the parameter.)

My initial plan was this:
- I want to share some AHK v1 code on the forum, but I want that code to be more forwards compatible, and therefore I would like InStr/SubStr/RegExMatch(/RegExReplace) to work like they do in AHK v2. Apply SetAhkV2Mode at the start of the subroutine, turn it off at the end.
- Also, I never liked how InStr/SubStr/A_OSVersion worked in AHK v1, so I would apply SetAhkV2Mode to all of my scripts.
- I had thought that there could be A_OSVersionName/A_OSVersion(Num) variables, for people who wanted them.

More generally:
- By adding the line '#SetAhkV2Mode' to an AHK v2 script (and by having the forwards compatibility library in the Lib folder), this would allow you to run that AHK v2 script in AHK v1.
- There are a few AHK v2 features that wouldn't work in AHK v1, namely binary variables, hence I wrote some two-way compatible functions like:
'essential':
JEE_FileReadBin
JEE_FileWriteBin
JEE_ClipboardFromFile
JEE_ClipboardToFile
'non-essential' (workarounds exist, but these functions are more practical):
JEE_Between
JEE_IsType
JEE_StrContains
JEE_StrExact ('StrIn' is confusingly similar to 'InStr')
JEE_StrSplitToVars (different from StringSplit, uses ByRef variables)
- I'm going to add these functions to an addendum to the forwards compatibility library (AHK v2 functions for AHK v1).
- It's so tempting to add in new features myself like StrRept/StrCount/StrJoin/StrStarts/StrEnds/StrMatch, binary to/from hex string, but I won't.

- Your comment about AHK v1 libraries is interesting.
- I had intended to convert all of my libraries to AHK v2.
- However, that seems like a reasonable request, to use an AHK v2 script with AHK v1 libraries, and could potentially be doable, using all of the principles I've already outlined e.g. the AHK v2 script might have to some incompatible features replaced with alternatives.

- One thing that should be considered, that I haven't mentioned, is versions of InStr/SubStr/RegExMatch/RegExReplace that work in AHK v1/v2, the same way they do in AHK v1. I am in principle opposed to this, however, if you want to convert some code to AHK v2 in a hurry and don't want to fiddle with the StartingPos values or RegExMatch 'O' mode, InStr1/SubStr1/RegExMatch1/RegExReplace1 would be valuable for this.
- [EDIT:] Omg I did create some '1' functions back in January.
conversion logic, v1 = -> v1 := -> v2, two-way compatibility - Page 3 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 40#p128540

- A common scenario is that you have some AHK v1 code from one source, and some AHK v2 code from another, and you're looking for the quickest way to combine the two in a workable form for testing purposes, before ironing out later.

- You seem to be asking why would someone want to run an AHK v2 script in AHK v1, and what limits would need to be put on that AHK v2 script to make that possible.
- Basically, I think that I've established most (possibly all) of the problems re. two-way compatibility, and I mentioned four File/Clipboard functions, and some other functions above. [EDIT:] See list below.
- If I wanted to confirm that some code was still two-way compatible, I'd run the same code in both AHK v1/v2. I'd have to be aware of things like binary variables, while writing/amending the code, that wouldn't be backwards compatible.

- [EDIT:] Hmm, I'm reminded of the idea of a SetAhkV1Mode for AHK v2, to handle things like InStr/SubStr. However, I'm also reminded of the reaction, that people did not want AHK v2 sullied in any way by any function used for backwards compatibility. Keeping that principle in mind, a workaround would be to replace instances of InStr/SubStr with the '1' functions above.

- [EDIT:] A list of things in AHK v2 not compatible with AHK v1.
ClipboardAll - binary variable
FileAppend - binary variable (RAW)
FileRead - binary variable (RAW)
InputBox - password character
FileInstall - will only perform a FileCopy
ListVars - can only list global variables
(probably won't be compatible: the new in/contains operators)

- [EDIT:] Re. little fixes. Trying to imagine how to implement SetAhkV2Mode in C++, I believe the changes would be relatively straightforward with 2 exceptions. 'Loop' can only appear at the beginning of lines making it, in theory, not too difficult to parse. I don't know how difficult converting `" to "" would be, potentially quite difficult, although that is the sort of thing that the parsers do already handle (identifying escaped characters).
- [EDIT:] I had wondered if AHK v1 could be made to handle both `" and "" at the same time, but my instinct would be that that would be fiendish. Even if you were clever enough to pull it off, the code could be monstrous, fiddly in the extreme, very difficult to support, or understand, or re-familiarise yourself with. Although maybe there are ways to do it, maybe there are approaches where it wouldn't be too bad. Parsing strings has been the meanest thing I've done in programming.
- I was hesitant about `" at first, I was fine with "", however, it's definitely much better to use `", far more readable. It's one of the few times I've changed my mind on something. Although, in my defence, I was concerned that text from any language (e.g. Excel sheet functions) that uses the "" style would have to be altered before being pasted into AutoHotkey, but ultimately this concern is very minor.

[EDIT:] Re. Time v. Date. I have a tonne of date/time functions in my dates library, and the distinction I make is: 'Time' functions for handling absolute amounts of time, 'Date' functions for handling datestamps.
coffee
Posts: 76
Joined: 01 Apr 2017, 07:55

Re: A_ variables

30 Dec 2017, 21:30

My initial plan was this:
- I want to share some AHK v1 code on the forum, but I want that code to be more forwards compatible, and therefore I would like InStr/SubStr/RegExMatch(/RegExReplace) to work like they do in AHK v2. Apply SetAhkV2Mode at the start of the subroutine, turn it off at the end.
And herein lies the problem with this, after all, it is not your problem but the user's to convert whatever is posted and make it compatible with their own libraries/version/system/3+-level-deep-custom wrapper functions/etc.
If you want that code to behave like v2, v3, like it's java or c++, then you are responsible to ship it with the required functions/libraries/dependencies/workarounds and let the user know, or simply state that it only works with "X".
More generally:
- By adding the line '#SetAhkV2Mode' to an AHK v2 script (and by having the forwards compatibility library in the Lib folder), this would allow you to run that AHK v2 script in AHK v1.
This is not considered autohotkey v2 development then. This is an autohotkey v1 bloature request, i.e make v1.1 work like v2 by changing function defaults. And since v1.1 versions are not about breaking old scripts, it would be about some function defaults and that's it. It will require changes to v1 documentation explaining yet this other way of doing things, or this other variant to the functions in question, more crap for new users to roll through. Some of the syntax changes can't be done at runtime. If SetAhkV2Mode will not run all v2 scripts in v1 unless you port all the changes on the syntax to v1 to make this switch possible, then it makes it 1. bloat, 2. a waste of time. If the eventual state of v1 is to have all the code changes of v2 with n times the binary size, then it's just a matter of who is actually going to waste time to do it.
It's a niche usage, that should be handled by an external module. You should just fork it and implement it yourself in source if you are in such a dire need of this. It's a stop gap measure that will be useless once you are all moved over, so if someone wants to continue using v1 just because, they now have this oversized and possibly slower binary. If the user is already in v2, then it becomes irrelevant. This is better handled by a separate thing rather than something permanent in the source.
Adapting a v1 script to the same v1 so that it's only partially compatible with v2 is not a logical approach, it's very half-assed.
- However, that seems like a reasonable request, to use an AHK v2 script with AHK v1 libraries, and could potentially be doable, using all of the principles I've already outlined e.g. the AHK v2 script might have to some incompatible features replaced with alternatives.
It would require a good converter that will output a v2 file and someone with the time to maintain it. You could make one :), or maybe you already have one. Syntactical differences don't have an on the fly alternative in v2 as far as im aware, unless you make an autohotkey "preparsing" interpreter on top of autohotkey, and that's just throwing more shit at the fan, adding inefficient code just to add it. Some v1 libraries also use some of the older v1 statements (like loop files and loop reg), that need to be taken into account. The standard library only takes you so far. You seem to be now be asking to port forward v1 to v2 so that it can handle all the % and strings without quotes and = as assignment. V2 running v1 libraries is not doable at runtime without bloating v2.

But again, there is a way to do this using an external module, which is more worthwhile to be honest. Using it raw or wrapping that module into an interface (i believe there is a wrapper floating around, dont remember) and throwing it at users that want to run untethered v1 code in v2. Or untethered v2 code in v1.
You already have a lot of the groundwork with Autohotkey.dll by HotkeyIt. If there is a sincere need to run incompatible code, grabbing the dll and working with it will probably end up being faster. That user will ship this dependency with whatever he is trying to do, unless he is aiming for cross compatibility with something like 2a078 or 2a079 or whatever the last one was that used % for everything.
- A common scenario is that you have some AHK v1 code from one source, and some AHK v2 code from another, and you're looking for the quickest way to combine the two in a workable form for testing purposes, before ironing out later.
Doing this and in the "quickest way" would be a very specific user's requirement. Which throws all the responsibility at the user. This is more like a personal anecdote than an actual use case, organizations have IT departments with policies to handle software deployment and situations like these.
- You seem to be asking why would someone want to run an AHK v2 script in AHK v1, and what limits would need to be put on that AHK v2 script to make that possible.
v2 scripts shouldn't be limited in any way just so that they are compatible with a hypothetical bloated v1 binary.
- [EDIT:] Hmm, I'm reminded of the idea of a SetAhkV1Mode for AHK v2, to handle things like InStr/SubStr. However, I'm also reminded of the reaction, that people did not want AHK v2 sullied in any way by any function used for backwards compatibility.
If it happens, it should be on a fork. Because it's unreasonable, unneeded and purely bloat, a need that can and should be met by an external module or a static converter.

You seem to be very requesty, requesting this, requesting that, requests that only fit your own personal use, your only need for your scripts. Who are you requesting this to if ultimately the one who seems to be so pushy about this is you?
You have been wasting at this for what? more than 8 months now? For such a persistent need through such a long time you would think you would have come up with whatever it is you need yourself. 8+ months debugging source you could have probably come up with your own 5 megabyte AutoHotkey_J fork by now.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

31 Dec 2017, 00:18

- Thanks for your response.
- From my perspective, you are overestimating the complexity. I think I'm coming up with a pretty good package for users: use my converter and functions library, and the proposed #SetAhkV2Mode, and you have two-way compatible libraries/scripts.
- The crux of #SetAhkV2Mode is to allow Loop with expression parameters in AHK v1. To allow `", and disallow "", would be a definite bonus. The other #SetAhkV2Mode elements are non-essential (there are workarounds), but round out the package.
- The situation is still shifting, force-local was introduced, and A_Args was backported. Changes like these can greatly facilitate two-way compatibility. If the ideas in #SetAhkV2Mode were not implemented at all, adding an /Inc switch (mentioned above) could facilitate some reasonably effective workarounds. There are a lot of AutoHotkey changes that could drastically change the situation, meaning certain things are best put lower down in the priority pile for now.
- I find it amusing that for a few people, not you, they are 100% fine with one-way conversion, but the moment you even whisper 'two-way compatibility', suddenly there's a problem. The work on two-way compatibility is a tiny addendum to the work on one-way conversion, with the immense benefit of having function libraries that have one version only, not two. I much prefer a bit of hacking and lateral thinking to get some two-way compatibility in working order, than maintaining two versions of all my function libraries. Of course, I'm against the idea of stunting an AHK v2 function library, to keep it two-way compatible, we'll cross that bridge when we come to it.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

18 Jan 2018, 11:08

Another idea, 'A_LoopFileAttribNum' (or an alternative name), is described here:
file loop listing the same files twice (identify redirected folders) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=42975
- Btw we would probably benefit from some sort of 'A_LoopFileAttribNum' variable for file loops, to reduce overhead, if wanting to check the attributes of every file in a folder/on the hard drive for special properties.
- The attribute number should already be available in the WIN32_FIND_DATA structure that the AutoHotkey file loop uses. E.g. see this example for more details:
259-char path limit workarounds - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 06#p170806
I didn't post the idea previously, because there wasn't an obvious need for it.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

29 Jan 2018, 11:20

- Since the Menu command was removed from AHK v2. This leaves one or two settings that cannot be set in a two-way compatible manner in AHK v1/v2:

Code: Select all

Menu, Tray, Click, 1 ;AHK v1
A_TrayMenu.ClickCount := 1 ;AHK v2

Menu, Tray, Icon ;AHK v1
A_IconHidden := 0 ;AHK v2

Menu, Tray, NoIcon ;AHK v1
A_IconHidden := 1 ;AHK v2

Menu, Tray, Tip, AutoHotkey ;AHK v1
A_IconTip := "AutoHotkey" ;AHK v2
- I've created a custom backport for A_TrayMenu.ClickCount here:
objects: backport AHK v2 Gui/Menu classes to AHK v1 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=43530
- I would recommend that A_IconHidden and A_IconTip be updated in AHK v1 to match AHK v2. [EDIT: A_AllowMainWindow would be another candidate.]
- Obviously I would welcome A_TrayIcon being backported to AHK v1, however, AFAICS this isn't *necessary* in the same way.
- I've recreated TraySetIcon here for AHK v1:
commands as functions (AHK v2 functions for AHK v1) - Page 2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 55#p197355
- There may or may not be other variables/settings affected, however, those are the ones that I have been using and am therefore aware of.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

14 Feb 2018, 13:50

- A_ThisHotkeyRaw (or another name). A_ThisHotkey but minus the leading *~$, which could be there, unintentionally, due to an unrelated hotkey.
- Either the variable always removes the leading characters, so 'q' for both hotkeys below, or otherwise it exactly matches the label: '~q' and 'q'.
- Example of the problem:

Code: Select all

#If WinActive("ahk_class WordPadClass")
~q::
MsgBox(A_ThisHotkey) ;~q
return
#If

#If WinActive("ahk_class Notepad")
q::
MsgBox(A_ThisHotkey) ;~q
return
#If
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

15 Feb 2018, 08:53

- I noticed this:
Removing many built-in (thread settings) variables in favour of functions. by HelgeffegleH · Pull Request #91 · Lexikos/AutoHotkey_L · GitHub
https://github.com/Lexikos/AutoHotkey_L/pull/91
- I was waiting for this to be discussed in 'Thoughts for v2.0', but now that it's been anticipated, I'll relay my findings from the 30th of January.
- With the new A_ListLines and 'A_' tray variables, it looked like the trend was to move towards 'A_' variables only, and away from 'SetXXX' functions. Thus I had thought that the commands that determine AHK settings might be removed completely (apart from ListLines which has other functionality). The opposite of Helgef's suggestion.

- Benefits of removing the commands:
- Getting/setting the variables is intuitive.
- Everything has a consistent prefix: 'A_'.
- The function index in the documentation is less cluttered.
- The command names and functionality do not have to be altered to make them consistent, they can just be removed.
- You can view all of the 'A_' variables in the script's main window.
- Some of the 'A_' variables already allow direct assignment, thus it would be confusing if some of them didn't, thus, they should all allow it.
- [EDIT:] Using 'A_' variables is far more intuitive than using the SetKeyDelay/SetMouseDelay commands.
- [EDIT:] You don't have to remember which commands start with 'Set' and which don't.

- I would definitely keep Client/Screen/Window for A_CoordModeXXX, and I would add in friendly names for A_TitleMatchMode (I can *never* remember the numbers), e.g. Starts/Contains/Exact/RegEx(/Ends) (S/C/X/R/E). I would remove On/Off for probably all of the variables, however On/Off can be good in commands. For A_StringCaseSense, 0/1/Locale seems like the best solution.
- Here is my summary:

Code: Select all

note: this list includes all of the SetXXX functions except SetTimer
note: perhaps the 3 SetXXXState commands could be replaced with a SetKeyState function, otherwise they could have A_ variables also

command - variable
[none] - A_AllowMainWindow
[none] - A_EndChar
[none] - A_IconFile
[none] - A_IconHidden
[none] - A_IconNumber
[none] - A_IconTip
CoordMode - A_CoordModeCaret/A_CoordModeMenu/A_CoordModeMouse/A_CoordModePixel/A_CoordModeToolTip
DetectHiddenText - A_DetectHiddenText
DetectHiddenWindows - A_DetectHiddenWindows
FileEncoding - A_FileEncoding
ListLines - A_ListLines
SendLevel - A_SendLevel
SendMode - A_SendMode
SetCapsLockState - [none]
SetControlDelay - A_ControlDelay
SetDefaultMouseSpeed - A_DefaultMouseSpeed
SetKeyDelay - A_KeyDelay/A_KeyDelayPlay/A_KeyDuration/A_KeyDurationPlay
SetMouseDelay - A_MouseDelay/A_MouseDelayPlay
SetNumLockState - [none]
SetRegView - A_RegView
SetScrollLockState - [none]
SetStoreCapsLockMode - A_StoreCapsLockMode
SetTitleMatchMode - A_TitleMatchMode/A_TitleMatchModeSpeed
SetWinDelay - A_WinDelay
SetWorkingDir - A_WorkingDir
StringCaseSense - A_StringCaseSense

note: 'lock'
'Lock' title case (more logical/more consistent with documentation):
MsgBox(Func("SetScrollLockState").Name) ;SetScrollLockState
'lock' lower case (less logical/less consistent with documentation):
MsgBox(Func("SetCapsLockState").Name) ;SetCapslockState
MsgBox(Func("SetNumLockState").Name) ;SetNumlockState
MsgBox(Func("SetStoreCapsLockMode").Name) ;SetStoreCapslockMode
Last edited by jeeswg on 22 Feb 2018, 20:09, edited 1 time in total.
Helgef
Posts: 3221
Joined: 17 Jul 2016, 01:02
Contact:

Re: A_ variables

16 Feb 2018, 07:34

A_ThisHotkeyRaw
So you have problems identifying which hotkey was triggered? That variable will not be very helpful.
All these ideas tells me we need to have hotkey objects... ;)
If we had hotkey objects, the question, which hotkey was triggered? would never be asked, the object would uniquely identify it. Well, it is not really needed, you just need to learn to use functions, and then you use your hotkeys with boundfuncs, which has a unique identifier bound to it.

Code: Select all

hotkey "ifwinactive", "ahk_class Notepad"
hotkey "~a", func("f").bind(1)
hotkey "ifwinactive", "ahk_exe calc.exe"
hotkey "a", func("f").bind(2)
f(this_hotkey){
	msgbox this_hotkey
}
The key:: notation is good for the quick 100-line script, not for any modular, more elaborate application.
Getting/setting the variables is intuitive
You have missed the important point about the suggestion, that is, setting and getting in one opertation.
Using 'A_' variables is far more intuitive than using the SetKeyDelay
Explicit example, highligthing the main point of the suggestion,

Code: Select all

pDelay := keyDelay(20, 30) ; set and get
; ...
keyDelay(pDelay*) ; restore

vs. (if only A_ variables where available)

Code: Select all

; Get
pDelay := A_KeyDelay
pDuration := A_KeyDuration
; Set
A_KeyDelay := 20
A_KeyDuration := 30
; ...
; restore
A_KeyDelay := pDelay
A_KeyDuration := pDuration

- Everything has a consistent prefix: 'A_'.
The functions consistently doesn't. The A_ prefix only tells you it is a built-in variable, not that is a script/thread setting. Your editor should highlight built-in functions.
- The function index in the documentation is less cluttered.
The built-in variable index in the documentation is less cluttered.
You don't have to remember which commands start with 'Set' and which don't.
None of the proposed functions starts with set.
You can view all of the 'A_' variables in the script's main window.
Can you? It would be good. But there is nothing saying you couldn't list the script/thread settings in the main window regardless of how they are set.

Cheers.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

16 Feb 2018, 14:57

- Your point about getting/setting in one go, is a good one, however, I would suggest instead, a generalised Assign function:

Code: Select all

vRV := A_RegView, A_RegView := 64
vDHW := A_DetectHiddenWindows, A_DetectHiddenWindows := 1
vOldValue := Assign(vMyVar, vNewValue)
oOldValues := Assign(vMyVar1, vMyVar2, vNewValue1, vNewValue2)
oOldValues := Assign(vMyVar1, vMyVar2, oNewValue*) ;if doable
- Such a function would also be useful for doing 'StrSplitToVars'.
- Btw I don't find the SetKeyDelay function to be the best example, it uses 3 parameters to assign 4 variables, it's highly confusing, even thinking about it now.
- Btw I haven't felt the inability to get/set in one go a major problem, and this is only usually required because functions lack a way to set a mode temporarily e.g. the ahk_dhw/ahk_mode window criteria suggestions fix this, as would a case-sensitive/options parameter for StrReplace.
- Btw one crucial problem with scrapping 'A_' variables: a variable that doesn't exist, silently fails, however, a function that doesn't exist, explicitly fails, so this could be a major source of bugs if old 'A_' variables don't work like they used to.
- I prefer to store settings in variables versus having functions that don't really *do* anything.

- Re. cluttered. I haven't ever found the built-in variable list to be cluttered. It's nicely separated into categories.
Variables and Expressions
https://autohotkey.com/docs/Variables.htm#BuiltIn
- If the SetXXX functions were to remain, I would suggest making them all of the form SetXXX corresponding to A_XXX. There would be separate 'ListLines' and 'SetListLines' functions in that case.

- Re. 'A_ThisHotkeyRaw'. It would be useful for things like if (A_ThisHotkeyRaw = vHotkey).
- Also, the current behaviour is newbie-unfriendly, and breaks the principle of least astonishment.
- There are workarounds, but I think the idea is worth a mention.
- Crucially, I'm not 100% sure what text to expect in A_ThisHotkey at present.

- Re. hotkey objects. Custom hotkey objects are fine (especially to keep track of which hotkeys are assigned), e.g. see the link, however, using hotkey labels and having one or two more 'A_' variables would also be good.
log hotkeys, get extended hotkey info, interact with the *right* window (Hotkey command with FunctionObject example) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=29560
Helgef
Posts: 3221
Joined: 17 Jul 2016, 01:02
Contact:

Re: A_ variables

16 Feb 2018, 17:25

a generalised Assign function
I do not think that is easily implemented to support built-in variables. They aren't really variables, you cannot pass them byref for example.
I haven't felt the inability to get/set in one go a major problem
It certainly isn't a major problem. There are currently two ways to set script settings, I think one is enough, and I prefer functions. But really, as it is, isn't bad.
SetKeyDelay [...] it uses 3 parameters to assign 4 variables, it's highly confusing,
The proposed new functions are KeyDelay(delay, duration) and KeyDelayPlay(delay, duration).
one crucial problem with scrapping 'A_' variables: a variable that doesn't exist, silently fails, however, a function that doesn't exist, explicitly fails
An excellent point in favour of functions :thumbup: . On a side note, having a warn mode to warn that a non-built-in A_ variable exists could be useful. Eg,

Code: Select all

A_DetectHiddenWindow := true ; Warn
I would suggest making them all of the form SetXXX corresponding to A_XXX
A_XXX doesn't correspond to SetXXX, A_SetXXX would. I do not think it is beneficial, but rather annoying. Having a summary of all script settings in the documentation would be nice, regardless of how they are set.
Crucially, I'm not 100% sure what text to expect in A_ThisHotkey at present.
As documented:
When a hotkey is first created -- either by the Hotkey function or a double-colon label in the script -- its key name and the ordering of its modifier symbols becomes the permanent name of that hotkey, shared by all variants of the hotkey.
Cheers.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

16 Feb 2018, 17:55

- Yes, I was thinking that the ByRef issue would need resolving, or having a separate 'set setting' function just for 'A_' variables.
- Yes, I was thinking that (Set)KeyDelay and (Set)KeyDelayPlay would be better than what we have currently, nice to see that it was part of your package. [EDIT: Although (Set)MouseDelayPlay would also be needed in that case. I'm now neutral re. leaving SetKeyDelay and SetMouseDelay as they are, or adding two additional SetXXXDelayPlay functions.]
- Haha 'An excellent point in favour of functions'. I was thinking that as I wrote it, it could be misused by the other side. The Warn idea is good. However, it can be useful to be able to backport certain variables e.g. A_InitialWorkingDir, so I would want to be able to specify some custom 'A_' variables as exceptions (to not trigger a warning), otherwise, functions have an IsBuiltIn method, something similar for variables could be good.
- One fundamental thing, I *like* 'A_' variables, and feel that the 'SetXXX' functions if kept, should be standardised, so if I could only keep one, it would be the 'A_' variables. Also, if you remove some 'A_' variables, you get the inevitable question, should *all* 'A_' variables be removed (I would like them all kept).
- Thanks for the documentation quote.
User avatar
jeeswg
Posts: 5265
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

27 Feb 2018, 07:21

- A_MsgBoxResult / A_InputBoxResult for AHK v1/v2.
- I would suggest A_InputBoxResult as an alternative to using ErrorLevel. When going through my scripts, I find that ErrorLevel, when used by InputBox, clutters up the scripts, making it harder to find other uses of ErrorLevel.
- Reinstating A_MsgBoxResult would then be consistent with A_InputBoxResult and would allow for the easy conversion of IfMsgBox, e.g. IfMsgBox, Yes to if (A_MsgBoxResult = "Yes").
- Because ErrorLevel is positional, a later function may overwrite the ErrorLevel value for the function you were interested in, potentially something like GetError(FuncName) could be useful. Note: I like the name 'GetLastError', however, this is already a well-known Winapi function, so that would cause confusion.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 6 guests