add A_LineDir|A_UserProfile|A_LocalAppdata
add A_LineDir|A_UserProfile|A_LocalAppdata
these usefull vars is omited all the time.
Re: add A_LineDir|A_UserProfile|A_LocalAppdata
What is A_LineDir should contains ?
Why not use EnvGet("UserProfile"), EnvGet("LocalAppData") ?
Please post your script code inside [code] ... [/code] block. Thank you.
Re: add A_LineDir|A_UserProfile|A_LocalAppdata
dir of A_LineFile
there are a lot A_xxx vars, A_UserProfile|A_LocalAppdata is much useful then some others.
so why not add these var in it.
there are a lot A_xxx vars, A_UserProfile|A_LocalAppdata is much useful then some others.
so why not add these var in it.
Re: add A_LineDir|A_UserProfile|A_LocalAppdata
"Why not ...?" I don't need to answer. If you want something to be done, you'd better provide a good reason to do it, or it won't be done.
These have almost certainly been requested multiple times. If you want answers, you could do some searching. (Here are some answers anyway...)
USERPROFILE and LOCALAPPDATA are standard environment variables. Why not retrieve environment variables using the appropriate function? Why bloat the program with redundant ways to retrieve specific environment variables? There are other variables that do this; adding them was a mistake in my opinion.
A_LineDir is also redundant; its value is contained by A_LineFile. Why not have A_..Dir, A_..Name, A_..NameNoExt, etc. for every variable that returns a path? Because it's a waste of code and documentation space. It is inelegant. If you want the directory from a path, use SplitPath. Or you can just use %A_LineFile%\...
Paths of some special directories are not available in environment variables. Built-in variables might be added for those (or a function wrapping SHGetKnownFolderPath).
These have almost certainly been requested multiple times. If you want answers, you could do some searching. (Here are some answers anyway...)
USERPROFILE and LOCALAPPDATA are standard environment variables. Why not retrieve environment variables using the appropriate function? Why bloat the program with redundant ways to retrieve specific environment variables? There are other variables that do this; adding them was a mistake in my opinion.
A_LineDir is also redundant; its value is contained by A_LineFile. Why not have A_..Dir, A_..Name, A_..NameNoExt, etc. for every variable that returns a path? Because it's a waste of code and documentation space. It is inelegant. If you want the directory from a path, use SplitPath. Or you can just use %A_LineFile%\...
Paths of some special directories are not available in environment variables. Built-in variables might be added for those (or a function wrapping SHGetKnownFolderPath).
- Animan8000
- Posts: 58
- Joined: 11 May 2022, 05:00
- Contact:
Re: add A_LineDir|A_UserProfile|A_LocalAppdata
Would it be maybe worth it to remove built-in environment variables, that can be retrieved with EnvGet anyway? At least for future versions of AHK. I don't even know if AHK's built-in (filepath) environment variables waste RAM even if the user never uses them in a script.lexikos wrote: ↑11 Dec 2022, 21:46USERPROFILE and LOCALAPPDATA are standard environment variables. Why not retrieve environment variables using the appropriate function? Why bloat the program with redundant ways to retrieve specific environment variables? There are other variables that do this; adding them was a mistake in my opinion.
Re: add A_LineDir|A_UserProfile|A_LocalAppdata
v2.x is required to be backward-compatible with v2.0, else it would be v3. Later v2.x releases might include a directive to opt in to backward-incompatible changes within a limited scope, but while this could remove deprecated items from the current namespace, the code implementing those items would still exist within the binary. It would be of use for easing into v3, but wouldn't reduce code size in v2.x or improve performance.
Any impact on memory usage or performance is insignificant. Code is held in virtual memory but may be mapped to the EXE file on disk, rather than RAM.
Any impact on memory usage or performance is insignificant. Code is held in virtual memory but may be mapped to the EXE file on disk, rather than RAM.