It seems that if the
! mIRC-internal-command prefix is applied to the—for lack of better term, "construct commands" (i.e., those which introduce a new scope like
/if,
/elseif,
/else, or
/while), mIRC will attempt to also apply the
! prefix's behavior to the first command that occurs in the newly created scope
if that command appears on the same logical line as the so-called "construct command". In other words, given:
alias -l local_alias { echo -ga local alias invoked }
alias pfxtest_1 {
!if ( $true ) {
local_alias
}
}
alias pfxtest_2 {
!if ( $true ) { local_alias }
}...calling
/pfxtest_1 will work as expected, while
/pfxtest_2 will cause mIRC to attempt to find and call an internal command named
/local_alias, then forward the command call to the active server when it fails to do so, rather than call the alias of the same name.
Though I don't include these tests in my sample script above for the sake of simplicity and readability, I've so far tested this behavior with several aliases of the following properties, with no variation in the behavior:
- local vs. global
- file-internal vs. file-external
- positioned-before vs. positioned-after (both script and file-wise)
- defined within remote file vs. within alias file
It also appears to make no difference whether or not
{ } / braces are used around the command, if a condition is wrapped in
( ) / parentheses when applicable, nor if the behavior-testing alias is called via script or editbox. Additionally, and as hinted at earlier, the buggy behavior will occur if the
$& identifier is used in an effort to visually split the custom command from the line that "construct command" appears on - e.g.:
alias pfxtest_3 {
!if ( $true ) { $&
local_alias
}
}(...I'm unsure why anyone would actually do this sort of thing though...)
This behavior does not (cannot?) occur if the alias is used as an identifier - e.g.:
alias pfxtest_4 {
!if ( $true ) { $local_alias }
}...will call
$local_alias as expected.
(Tested on a clean installation of mIRC v7.71 on windows 10 home edition.)
