Are two #DefineCommand directives in conflict?
I have got a simple script that uses the #DefineCommand directive:
#DefineCommand, GetFilePath, LblGetLinksFilePath
^+q::
GetLinksFilePath, Result, /some/path/
MsgBox, Result: %Result%
return
LblGetFilePath:
lfp_Name = file-peekaboo.txt
lfp_Path = %A_Param2%
lfp_File = %lfp_Path%%lfp_Name%
%A_Param1% = %lfp_File%
return
And it works. But when I put another #DefineCommand in and use the new command in the definition of GetFilePath:
#DefineCommand, GetDate6, LblGetDate6
#DefineCommand, GetFilePath, LblGetFilePath
^+q::
GetFilePath, Result, /some/path/
MsgBox, Result: %Result%
return
LblGetDate6:
StringRight, d6_Year, A_YYYY, 2
d6_DateString = %d6_Year%%A_MM%
%A_Param1% = %d6_DateString%%A_DD%
return
LblGetFilePath:
GetDate6, lfp_DateString
lfp_Name = links-%lfp_DateString%.txt
lfp_Path = %A_Param2%
lfp_File = %lfp_Path%%lfp_Name%
%A_Param1% = %lfp_File%
return
the Result variable is empty.
If MsgBox commands are put inside GetFilePath to check values of the variables:
LblGetFilePath:
GetDate6, lfp_DateString
lfp_Name = links-%lfp_DateString%.txt
MsgBox, lfp_Name: %lfp_Name%
lfp_Path = %A_Param2%
MsgBox, lfp_Path: %lfp_Path%
lfp_File = %lfp_Path%%lfp_Name%
MsgBox, lfp_File: %lfp_File%
%A_Param1% = %lfp_File%
MsgBox, A_Param1: %A_Param1%
return
one can see that all goes well up till the file path is computed and stored in the lfp_File variable. Then the value is not assigned to the A_Param1.
Do I make a mistake in the above code?
I would be grateful if you could look into the (supposed) conflict of the two command definitions.
Than you for your help.
Right, that's a bug I hadn't thought of when developing it. Thing is, the logic for #DefineCommand is very basic, all it does is internally transforming e.g.
GetDate6, lfp_DateString
into
A_Param1 = lfp_DateString
GoSub, LblGetDate6
A_Param1 =
and thus, A_Param1 is unavailable inside LblGetFilePath once you've called GetDate6 with it.
I probably won't be fixing this very soon though, so I guess the workaround for now is to save your params into separate variables at the beginning of your routine once, at least if you're indending on calling other defined commands with it:
#DefineCommand, GetDate6, LblGetDate6
#DefineCommand, GetFilePath, LblGetFilePath
GetFilePath, Result, /some/path/
echo, Result: %Result%
return
LblGetDate6:
StringRight, d6_Year, A_YYYY, 2
d6_DateString = %d6_Year%%A_MM%
%A_Param1% = %d6_DateString%%A_DD%
return
LblGetFilePath:
out_path = %A_Param1%
lfp_Path = %A_Param2%
GetDate6, lfp_DateString
lfp_Name = links-%lfp_DateString%.txt
lfp_File = %lfp_Path%%lfp_Name%
%out_path% = %lfp_File%
return
Result: /some/path/links-240804.txt
Hello,
thank you for a quick reply and a recipe for a workaround. Makes sense.
While struggling with the issue, I realized … well, this is quite obvious, but I write it for those who would happen to read this:
There is no isolation of variables in the script, no separate scopes - all variables are global. Labeled fragments of code are not scopes either.
(It took me a while because I was influenced by the goodies offered by AHK ver. 1.1 and above :-) ).
This is by no means an accusation or complaint, just an observation. Tell me please, if I am wrong.
That is why I started using prefixes for variable names as shown in the above snippets.
Thank you for your help and for AHK_X11!
no, you're right, and it makes sense to add some custom scoping like you did imo!
Thank you for confirmation.