Update
I've updated the build with a new experimental feature:
Code: Select all
^a::
^b::
pressing_ctrl_a_or_b_calls_this_function() {
MsgBox %A_ThisHotkey%
}
This was previously prohibited by load-time validation. There can be many hotkeys or (#If) hotkey variants stacked above the function definition. Regular labels and hotstring labels pointing at function definitions are still prohibited. Having any other executable line (like an assignment) between the hotkey and the function definition will cause the hotkey to behave as before. The function name must, as always, be unique.
This is
not equivalent:
Code: Select all
^a::
^b::
pressing_ctrl_a_or_b_calls_this_function()
return
pressing_ctrl_a_or_b_calls_this_function() {
MsgBox %A_ThisHotkey%
}
Specifically, if execution "falls into" the hotkey label from above, it will skip over the first form but not the second form. The exception is that the script's first hotkey always acts like
return (because the loader inserts one to end the auto-execute section).
These forms are
not supported and will act as before:
Code: Select all
^a::fun() ; Function call.
{ ; Empty block which will never execute.
}
^b::fun2() { ; Function call followed by unexpected "{".
}
Forward Compatibility
Currently when a function is used with a hotkey, timer, GUI control, etc. the function is allowed to define optional parameters. If a script does this and relies on the fact that hotkeys, timers, etc. don't pass any parameters, we won't be able to later add parameters without breaking the script. Therefore, before these features are merged into the main branch, we must decide whether to pass any parameters, and exactly what parameters to pass. Alternatively, functions which accept parameters could be prohibited for now to preserve forward-compatibility.
Backward Compatibility
When the program searches for a label or function by name, functions which require parameters are skipped over. This is mainly for simplicity, but also has implications for backward-compatibility.
- If a function GuiClose(x) is defined, the GUI does not call it -- as before.
- If a function GuiClose() is defined and a GuiClose: label is not, the GUI calls the function on closing, which might be unexpected.
If an older script specifies a label name and a function also exists by that name, the behaviour changes from "label does not exist" to calling the function instead. I think the chance of this occurring is very small, and it would only be a problem if the script is designed to expect the "label does not exist" exception.