A_ variables

Discuss the future of the AutoHotkey language
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: A_ variables

28 Feb 2018, 04:28

you get the inevitable question, should *all* 'A_' variables be removed
I'm definitely leaning in this direction. I think it would probably be ok to leave some true constants, such as A_AhkVersion, A_PtrSize and what else there might be. Note, for many of the BIV's, there is not just simple function substitution, eg, the hotkey BIVs, it needs restructuring the hotkey concept. Ofc, it is not going to happen :lol:.
- A_MsgBoxResult / A_InputBoxResult for AHK v1/v2.
It is not a good idea imo. (Surprised?)
ErrorLevel is positional
A_XXXResult will have the same limitiation, as will GetError(FuncName). Further A_XXXResult will either increase thread overhead or cause the same inconsitencies with interruptions as, eg, A_ThisHotkey. The solution is to store errorlevel in a variable when needed, so ofc, errorlevel shouldn't be used in v2 (for inputbox). The function(s) should return all that is needed. For example, something like this,

Code: Select all

[text, errorlevel] := inputbox(...)
 ; or 
errorlevel := inputbox(textOut, ...)
where errorLevel symbolises the content which is currently stored in the variable errorlevel when inputBox() returns.

As a side note, I'd prefer A_InputBoxResult (or another name) over errorlevel, but as indicated above, it would just be a bit less worse.

Cheers.

Edit: to be clear, my use if the word should indicates my preference, not my demand.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

28 Feb 2018, 17:04

- I suppose my best solution is to do one-liners every time I use ErrorLevel, to make it clear what function it corresponded to: Func(Arg1, Arg2), vError := ErrorLevel.
- Although this has to be done every time I use InputBox, hence why A_InputBoxResult seems sensible.
- Where possible, I remove ErrorLevel and use the function's return value instead.
- Are there problems re. thread-specific values for A_ variables at present? I did consider that.
- For custom functions, you set settings via super-global variables, not functions, right? A_ variables are greA_t.

- It's classic how when you move to functions, all the obvious things, that were impossible before, start becoming apparent. I'm seeing now how much better my scripts would have been had functions become the norm back when Poly started that commands as functions library. Using function output values directly, lessening the frequency of ErrorLevel use, one-liners, no in/contains limitations, more efficient code. On the flip side, those functions might have constrained development, we got StrReplace and the removal of subcommands, for example, versus clones of the commands.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
sttrebo
Posts: 68
Joined: 27 Jan 2014, 12:31

Re: A_ variables

28 Feb 2018, 17:37

not sure if this has been requeted or not, if it has my apologies. any chance of having some user specified variables, A_Userxx, etc. Something that we could specify and then call from any script? this would give us the opportunity to read variable contents in different scripts without needing to use ini's or 'onmessage' statements.

if you've already dealt with this, please ignore this post.

thanks
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: A_ variables

01 Mar 2018, 02:53

Are there problems re. thread-specific values for A_ variables at present?
I mentioned A_ThisHotkey, the problem is that it is not thread specific, as documented.

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

Re: A_ variables

02 Mar 2018, 06:13

@Helgef: Re. these, rather than creating separate 'Play' commands, I had been thinking of something like Noesis's suggestion below, and/or to add further A_ variables. Since I never use the 'Delay' commands, I hadn't thought about this problem too much.
SetKeyDelay - A_KeyDelay/A_KeyDelayPlay/A_KeyDuration/A_KeyDurationPlay
SetMouseDelay - A_MouseDelay/A_MouseDelayPlay
Remove or alter the line "SendMode Input ; Recommended for new scripts due to its superior speed and reliability" - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 48#p203648
Noesis wrote:I tend to think that a better solution to this would be a change to SetKeyDelay so the options for the last parameter could be Play|Input
@sttrebo: That sounds like something that would require a change to the AutoHotkey source code, or a file that is always included. The best solution seems to be, in each script where you want a special variable, to have a function called XXX_MyFunc (or MyFunc), and a script called XXX.ahk (or MyFunc.ahk) that gets auto-included, that uses a super-global variable. That would work if the variable contents never change, otherwise you would need some way of communicating between scripts.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

20 Sep 2018, 07:44

- I've written C++ code to fill out certain A_ variables, all useful for #Include, from 4 to 8:

Code: Select all

A_AhkDir [proposal][already in AutoHotkey_H]
A_AhkName [proposal]
A_AhkNameNoExt [proposal]
A_AhkPath
A_ScriptDir
A_ScriptFullPath
A_ScriptName
A_ScriptNameNoExt [proposal][consistent whether script compiled or not][useful for 'A_DlgTitle' idea for MsgBox/InputBox/GUIs etc]
- Since I don't compile scripts, I had to investigate what these variables return for compiled scripts. Here's a summary:

Code: Select all

variables:
A_AhkPath
A_ScriptDir
A_ScriptFullPath
A_ScriptName

e.g. script (path of AHK exe and script, both in use):
C:\Program Files\AutoHotkey\AutoHotkey.exe
C:\MyDir
C:\MyDir\MyScript.ahk
MyScript.ahk

e.g. compiled script (expected path of AHK exe, not in use, path of compiled script, in use):
C:\Program Files\AutoHotkey\AutoHotkey.exe
C:\MyDir
C:\MyDir\MyScript.exe
MyScript.exe
- It might be useful if there was a directive option such that the A_AhkXXX variables would match the A_ScriptXXX variables in compiled scripts. (I.e. A_AhkPath := A_ScriptFullPath for a compiled script.)

- Anyhow, the exact nature of the A_AhkXXX variables for compiled scripts required a decision to be made, when I worked on the C++ code.
C++: AHK source code: potential A_ variables - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 23&t=54419

- Links:
Scripts - Definition & Usage | AutoHotkey
https://autohotkey.com/docs/Scripts.htm#ahk2exe
Variables and Expressions - Definition & Usage | AutoHotkey
https://autohotkey.com/docs/Variables.htm#AhkPath
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
coffee
Posts: 133
Joined: 01 Apr 2017, 07:55

Re: A_ variables

22 Sep 2018, 14:39

A_ScriptName defaults to filename + ext at startup. But A_ScriptName != filename.
A_ScriptName is a user writable variable, it can be set to anything you want.
A_ScriptNameNoExt becomes 100% senseless if user writes their own value to A_ScriptName. So A_ScriptName now has my custom name, and A_ScriptNameNoExt is what? a reference to the filename without the extension? Nah...

To me, it makes more sense that:
A_ScriptName would contain, at runtime, the name of the file without the extension and is writable, i.e that's the only relation it has to filename, after it's user set it has 0 link to it.
A_ScriptFileName would contain at runtime, the name of the file with the extension and is read-only.
or
A_ScriptFileName -> name without extension, read only.
A_ScriptFullFileName/A_ScriptFileNameExt -> name with extension, read only.

Either way, since this is for convenience's sake (anything can be derived from a_scriptfullpath), it's a good idea that a distinction is made between information that can be user-customizable (name) and information that can't be user-set or that won't change at all once script is running (filename should be considered fixed, similar to A_ScriptDir or A_ScriptFullPath, these won't go around changing), if you are pushing this in your own repo.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

22 Sep 2018, 14:57

- Thanks for your comments @coffee.

- Sorry if I'm repeating earlier comments.
- In AHK v1, A_ScriptName was just the name of the script (full path minus dir).
- I like that in AHK v1, A_AhkXXX and A_ScriptXXX reliably give you file locations. I would have them all read-only (but perhaps changeable by directives at load time). And all my scripts depend on those variables being constant.
- I like the idea of being able to change the default GUI/MsgBox/InputBox title, however, instead of making these dependent on A_ScriptName, I would use a new variable e.g. 'A_DlgTitle' or some such. (I want a variable to give me the script name, and I want a variable to change the default GUI title, having them as the same variable introduces awkwardness.)
- To me it would seem better that the default window title would not include the file extension, so in every script I would do: A_DlgTitle := A_ScriptNameNoExt.
- The 'NoExt' variables are very useful for including a file with the same name as the script/compiled script, but a different extension. Or for having a settings file included for each AutoHotkey exe.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_ variables

13 May 2019, 03:05

Are A_ variables generally going to be made writable in AHK v1/v2?
E.g. A_StringCaseSense := 1.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: A_ variables

13 May 2019, 16:57

No, they are not going to be made writable. They are writable in v2.

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 40 guests