Uhh there's no problem with the last code you posted, it works just fine as it should. It would only start becoming a problem if $2- contains commas, but for the raw 403 that will never happen. $2- will evaluate to "blah No such channel" and that is what will be shown in the input box, what's wrong about it?

Anyway, in response to your original post:

mIRC does allow for a string containing commas to be passed as a parameter to an identifier, as long as it is within a variable or within an identifier. You cannot put a string containing commas directly in an identifier because mIRC wouldn't be able to tell where the string ends and the second parameter starts. Since it will assume that the first comma it encounters is the end of the string, it will usually result into a "too many parameters" error report.

Now what exactly is the trick about passing strings with comma's in a var or token about? I guess it's best explained with an example:

1) //tokenize 32 a,b,c | .timer 1 0 echo -a $gettok( $1 ,1,44) | timers

The /timers command shows this:

* Timer 1 1 time(s) 1ms delay echo -a a

A timer evalutes the parameters passed to it 2 times. First time when passing parameters to it (this is standard procedure in mIRC when using double slashes from the command line, or in a script). The second time is when the timer is triggered. So let's apply this to our example.

1st evaluation: the timer command changes to .timer 1 0 echo -a a
2nd evaluation: timer is triggered and it simply echoes an a

Why didn't mIRC have any trouble with the fact that $1 is a,b,c? Well, mIRC sees three parameters: $1, 1 and 44. Even though $1 contains commas when evaluated, it doesn't matter mIRC already knows those are part of the first parameter.

2) //tokenize 32 a,b,c | .timer 1 0 echo -a $!gettok( $1 ,1,44) | timers

The /timers command shows this:

* Timer 1 1 time(s) 1ms delay echo -a $gettok( a,b,c ,1,44)

The result here is that you get the error message: * Too many parameters: $gettok

You immediately see why the error occurs from the message from the /timers command. Here mIRC will also evaluate the $gettok, but now it doesn't see 3 parameters, but 5, so it results into an error message.

I hope you see the subtle difference: because of the /timer command being used (same applies to scon/scid) you have to take into account double evaluation. My second code clearly shows that it ends up being the same thing as directly passing a string with commas to the $gettok identifier rather than passing it in a variable or token.


Gone.