mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Searched and didn't find mention of this. To demonstrate, create script filename test456.mrc and put this as line #1:

alias test123 { echo -s Line $scriptline of $script }

now paste this line in your status window:

//echo -s first message | unload -rs non_existentscript.mrc | echo -s 2nd message | test123 | echo -s last message

in mIRC 6.16, you see in status window:

first message
2nd message
Line 1 of C:\mirc\test456.mrc
last message

in mIRC 6.21, you see in status window:

first message
2nd message
Line 1 of C:\mirc\test456.mrc
* /unload: no such file 'non_existentscript.mrc' (line 1, test456.mrc)

... without displaying the 'last message'. It appears to be caused by mIRC no longer completely ignoring the failure to unload a script filename that doesn't exist. However, 6.21 generates an error message showing the wrong location for the error. mIRC seems able to continue on doing some things, as evidenced by echo'ing the 2nd message and calling the alias, but then seems to belatedly notice the error as it returns from the alias, thus generating the error as if the problem were within the alias, and doesn't continue the script past that point.

Any alias or scripted identifier you use in place of test123 will cause the error message to show as if the error was in that alias. Using a built-in identifier like $version or $ial doesn't halt the script and generate the misleading error message.

Instead of having the unload command and echo messages be a single line pasted in the status window, I changed them to all be on separate lines of alias test789 below the test123 alias within test456.mrc. The error line changed to be reported as the line containing "alias test789". When I move the test789 alias to a different script, and put another dummy alias below the test123 alias, mIRC 6.21 reports that dummy alias's line as the location of the error. This part made it hard to trace down the bug, because not only was the /unload error halting the script like it didn't before, but it was reported in the wrong script file, and was also reported as being in the next unrelated alias located in that wrong script file.

Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
The problem in my opinion is that /unload does not halt the script immediately in 6.21; if it is to report an error however, it will have to. I'm not sure if this is intentional, but I can't see any advantages to it (except perhaps making up for poorly written scripts). Changing this would probably also take care of the problem you reported.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
I agree, it should either go back to the old way of continuing past a failed unload, or stop at that point instead of continuing on until the next alias.

Joined: Dec 2002
Posts: 580
N
Fjord artisan
Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
I thought I was going to write you a script based fix, but found out error handling code doesn't pick up on this...

Code:
alias unload {
  unload $1-
  goto end
  :error
  echo -s shouldn't this happen if unload is giving a "no such file" error?
  echo -s but you will never see this message (in 6.21).
  reseterror
  :end
}


Note: the name of the alias didn't make a difference...


NaquadaBomb
www.mirc-dll.com
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
As was already discussed, the error is generated after the calling routine (or any alias called from within it) ends. If you wanted to implement such a fix, you'd have to at least do something like this:
Code:
alias unload {
  $iif(!$show,.) $+ unload $1-
  return $dummy
  :error
  if (? /unload: no such file * iswm $error) reseterror
}
alias dummy { }


Edit: corrected typo

Last edited by qwerty; 24/04/07 07:57 PM.

/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Quote:

$iif($show,.)


Have you done that backwards or is that intentional? (the way you've done it means if no . is used to call the alias, a . will be used to call /unload).

Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Oops, missed a ! there, thanks smile


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
In that case, something else you might be unaware of is that mIRC automatically prefixes /commands inside an alias with a . if the alias itself was called with a .

That means if you had the following alias:

Code:
alias echo2 { echo $1- }


And you called it as /.echo2, it would be equivalent to having this:

Code:
alias echo2 { .echo $1- }


You can test this by trying /echo2 -q <whatever> and then using a . too: /.echo2 -q <whatever>

In short, just using 'unload' instead of '$iif(!$show,.) $+ unload' will be fine.

I can't remember who told me this but it's a pretty handy feature smile

Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Indeed I was unaware of this, good to know! cool


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I will make /unload halt on error in the next version. It doesn't currently halt on error because users requested that behaviour in older versions of mIRC when error handling wasn't available.


Link Copied to Clipboard