AutoHotkey Community

Hi,

It might be nice to have a variable containing the whole command line which was passed to the script like $CmdLineRaw in AutoIt3.

Comp. also http://www.autohotkey.com/forum/topic54779.html
Tobias

I have posted an answer.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

DllCall("GetCommandLine", "str") (without the A) is Unicode-friendly.

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

Oh that is good to know. In standard AutoHotkey, should we use the Unicode friendly version also?

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

Hm my posting here was just to suggest an improvement as, in my point of view, it is much easier when I find a documented function / variable in the help (which is in my point of view perfect for AHK). Doing a DllCall does it as well but ok... that's up to the point of view of the dev

And posted it here as well as I found such a function in the AutoIt and AHK is my prerferred "automating" language

If you want to port your script to Unicode in the future then it'll be easier

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

FYI, that's one thing that is now covered in my documentation: Script Compatibility - DllCall
Standard (or "mainstream") AutoHotkey is an ANSI build. It also notes where it differs from AutoHotkey_L ANSI builds.

As for the original topic: One of the things under consideration (long ago!) for v2 was replacement of %0% %1% etc. with some built-in variables or a built-in function. For instance, infogulch suggested A_0, A_1, etc., JSLover(?) suggested A_Param1, A_Param2, ...

I think the current issues are obscurity (things like if 0 > 1) and the lack of support for them directly in expressions. If they were replaced with a built-in function, it could return all parameters when the parameter number was omitted:
Naming may be difficult: do we want clarity or brevity?

...I have current working (unreleased) code for A_Param1, A_ParamN...but it's not as useful as I'd like (parsing params based on order)...so I plan on writing universal command line getting/parsing code...


...my working function name is ParamGet()...

I have made a parser for options, it is not made for the command line. It could parse the command line of some programs also, but that was not the reason why I made it. May be you find it useful or you can rework on the source for that: argp - Argument Options Parser

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

If it's up for a vote I favor the old Borland Pascal
ParamStr function where ParamStr(0) is the name of the program itself and ParamStr(1) the first command line arg etc.. ParamCount return the number of args.

...I know nothing about Borland, but based on DOS or something else (not sure what) I prefer that too. In my current code A_Param0 gets the exe name & A_Param1 is the 1st Param & A_Params is the number of params...param 0 should not be the number of params (like it is in AHK's %0%)...