$istok behavior ? - mIRC Discussion Forums

If a $istok has 4 parameters, mIRC don't returns any error and if the third parameters isn't a number, the $istok always returns $true, (tested on 6.31,6.3,6.21 and 6.16)
This can be really annoying in some case.

Some exemple :

Code:

//echo -a $istok(1,2,3,4) return $false
//echo -a $istok(1,2,987361234,3) retun $false
//echo -a $istok(1,2,n,4) return $true

I think all of the exemple should return * Too many parameters: $istok

check this out!

Code:

//echo -a $istok(.,.,1a,.) - $istok(.,.,2a,.)

=> $true - $false

:S

Lol, very odd.
I can't explain this because with 2 or 5 parameters, mirc return an error.

Odd as all of the results are, it seems to me that when used correctly, it seems to work correctly.

It should still return an error message whenever it's used incorrectly, just in case someone who isn't very familier with it, knows it doesn't work for them because they're using it wrong.

*Mpdreamz smells a hidden/undocumented/unfinished routine for 4 parameters!

* RoCk nods

Originally Posted By: RoCk

Odd as all of the results are, it seems to me that when used correctly, it seems to work correctly.

True, i found this with a typo

Originally Posted By: Mpdreamz

*Mpdreamz smells a hidden/undocumented/unfinished routine for 4 parameters!

Ha ha, maybe, but i don't see how $istok should works with 4 parameters, *see the post of jaytea*

Originally Posted By: Mpdreamz

*Mpdreamz smells a hidden/undocumented/unfinished routine for 4 parameters!

I tried all of those on v5.5 with the same results, so it's been there since $istok was added.

//echo -a --> $version $istok(1,2,3,4)
--> 5.5 $false

//echo -a --> $version $istok(1,2,987361234,3)
--> 5.5 $false

//echo -a --> $version $istok(1,2,n,4)
--> 5.5 $true

//echo -a --> $version $istok(.,.,1a,.) - $istok(.,.,2a,.)
--> 5.5 $true - $false

Hum, not sure how considering this

Actually i have :

Code:

elseif ($istok(96 64.112 64.96 80.112 80.128 80.128 64. $&
    .144 64.144 80.0 112.16 112.16 128.0 128.32 128.32 112. $&
    .48 112.48 128.64 128.64 112.80 112.80 128.96 128.96 112. $&
    .112 112.112 128.0 144.16 144.16 144.16 160.0 160.0 176. $&
    .16 176.16 192.0 192.32 192.32 176.48 176.48 192.32 160. $&
    .48 160.32 144.48 144.64 144.64 160.80 160.80 144.64 176. $&
    .80 176.64 192.80 192.,$1 $2,46)) return 32 32

This way, the code works as it should but first, i've tryed :

Code:

elseif ($istok(96 64.112 64.96 80.112 80.128 80.128 64. $&
    144 64.144 80.0 112.16 112.16 128.0 128.32 128.32 112. $&
    48 112.48 128.64 128.64 112.80 112.80 128.96 128.96 112. $&
    112 112.112 128.0 144.16 144.16 144.16 160.0 160.0 176. $&
    16 176.16 192.0 192.32 192.32 176.48 176.48 192.32 160. $&
    48 160.32 144.48 144.64 144.64 160.80 160.80 144.64 176. $&
    80 176.64 192.80 192.,$1 $2,46)) return 32 32

And i've seen that all match X Y on the left (144 64,48 112,112 112,etc...) are not detected whereas i'm sure about $1 and $2.So i've tryed :

Code:

elseif ($istok(96 64.112 64.96 80.112 80.128 80.128 64 $&
    .144 64.144 80.0 112.16 112.16 128.0 128.32 128.32 112 $&
    .48 112.48 128.64 128.64 112.80 112.80 128.96 128.96 112 $&
    .112 112.112 128.0 144.16 144.16 144.16 160.0 160.0 176 $&
    .16 176.16 192.0 192.32 192.32 176.48 176.48 192.32 160 $&
    .48 160.32 144.48 144.64 144.64 160.80 160.80 144.64 176 $&
    .80 176.64 192.80 192.,$1 $2,46)) return 32 32

And in this case, it's all the match on the right that are not detected.

Is this a bug or a someone have an explanation

?

The $istok behavior hasn't been fixed in mIRC 6.32

And i'm still looking for an answer about the $& part, i think it's a bug because if i use a space as a token, it works fine, but with any other token, i have to use $+ $&.

The $& thing is normal. When you use

Code:

$istok(96 64.112 64.96 80.112 80.128 80.128 64. $&
    144 64,$1 $2,46)

that translates to

Code:

$istok(96 64.112 64.96 80.112 80.128 80.128 64. 144 64,$1 $2,46)

Notice the space between . and 144: the period-separated token is now " 144 64", not "144 64", so it will never match "$1 $2". In this respect, $& is not like $+ but like all other identifiers: if there's a space before $&, it will be included in the "translated" single line.

That's why using $+ $& works, Thank you

The reason for this is that $istok() is a special case of $findtok() and uses the same routine. I can make $istok() return an error on four or more parameters, however there are probably quite a few identifiers that don't return an error if you use too many parameters.

Currently, the behaviour with the third parameter seems to be that it specifies how many tokens have to be present in the text in order to return $true.

i.e.:

Code:

$istok(a.b.c.d.d.d.e,d,3,46) returns $true
$istok(a.b.c.d.d.d.e,d,4,46) returns $false because there are only 3 tokens of "d".

In my opinion, it's a useful addition to $istok, and instead of returning an error for four parameters, I think it would be nice to see the third parameter documented.

Hum, yes, could be useful