$isalias(sfile) is $false. - mIRC Discussion Forums

I don't get it. Why would $isalias(sfile) echo false?
When i try to $sfile an executable it returns the folder,
I'm completely at a loss here.

XP PRO SP2
mIRC 6.21

Quote:

I don't get it. Why would $isalias(sfile) echo false?

Because $sfile is not an alias, but a built-in identifier.

Quote:

When i try to $sfile an executable it returns the folder,

It works correctly here, make sure you have the trailing \ in the dir field.

Code:

//echo -a $sfile(*.*,$+(Choose the executable file of your media player))

This returns

Code:

C:\Program Files\Winamp\

for winamp.exe for example. (Not for me, but for kupotek.)

I don't know why it would do that for him.

//echo -a $sfile(*.*,$+(Choose the executable file of your media player)) <-- this is me

C:\Program Files\Winamp\winamp.exe <-- this is me

How about you?

It's working great here, too. I use this in my mp3ad+ script, but it's not working for kupotek. So he told me about this problem.
$isalias(sfile) is $false, so the alias is not overwritten by some other script or something. So it has to be a mIRC bug/problem, right?!

I would call it a bug if it were happening for you and me too, but it's only happening to him. Has he tried different exe's in different directories with the same results? What about $msfile .. does that behave the same way for him?

//echo -a $msfile(*.*,$+(Choose the executable file of your media player)) $msfile(1) <-- this is msfile

1 C:\Program Files\Winamp\winamp.exe <-- this is msfile

~ Edit ~

For qwerty

Thanks to qwerty for my education in evaluation brackets in this thread, I know this...

Code:

//echo -a $msfile(*.*,$+(Choose the executable file of your media player)) $msfile(1) <-- this is msfile

1 C:\Program Files\Winamp\winamp.exe <-- this is msfile

can be replaced using this...

Code:

//echo -a $msfile( [ $msfile(*.*,Choose the executable file of your media player) ] ) <-- this is msfile

C:\Program Files\Winamp\winamp.exe <-- this is msfile

Originally Posted By: RoCk

Has he tried different exe's in different directories with the same results?

Yep, he chose a file in the mirc directory and the result was his mirc directory.

I'd suggest that kupotek copy and paste the exact line of code he is using when getting these results.

Glad you liked jaytea's article

In this case however, evaluation brackets are not necessary. That's because the order of evaluation of nested identifiers is exactly the same as that of square brackets: the innermost element is evaluated first (if at the same depth, the order is from left to right). So in something like $a($b($c,$d)), the order of evaluation is $c, $d, $b, $a. In the case of $msfile, the inner one is evaluated first and returns the number of selected files; by the time that inner $msfile returns, mirc has already set up the data structure needed by the outer $msfile, so the latter will work correctly.

So why do we ever need evaluation brackets? Because without square brackets, the evaluation of inner identifiers will not change the way mirc separates the arguments of the outer identifier, ie in $a($b,$c), mirc determines that $a has been passed 2 arguments, even if $b or $c return something that contains a comma or a ). However, when brackets are used, things are different: in $a( [ $b ] ) for example, mirc evaluates $b before it has even begun parsing $a.

In short, square brackets inside identifiers are mainly (but not exclusively) used when a dynamic number of arguments is desired.

I just had another bug report of a user of my mp3ad+ script, where $sfile returned the path and not the complete path + filename.

Code:

$sfile(*.exe,$+(Choose the executable file of your media player))

returned

Code:

C:\Programme\iTunes\

He tried to get other files, too. Always with the same result: it returned the path. Same for $sfile with different parameters, e.g.

Code:

$sfile(itunes.exe,itunes.exe)

Code:

$isalias(sfile)

returned $false, so he didn't have any custom sfile alias, too.

Code:

$msfile(*.*,$+(Choose the executable file of your media player)) $msfile(1)

returned

Code:

He uses mIRC 6.31 (with NNScript 4.2).

P.S.: this thread should get a different subject and should be moved to bug reports section.

It worked correctly here...

//echo -a --> $sfile(*.exe,Choose the executable file of your media player)
--> C:\Programme\iTunes\itunes.exe

//echo -a --> $msfile(*.exe,Choose the executable file of your media player) $msfile(1)
--> 1 C:\Programme\iTunes\itunes.exe

v6.31 - XP Pro SP2 - NTFS

~ Edit ~

Originally Posted By: voks

...should be moved to bug reports section.

I would agree, if it were a problem with mIRC.

Working fine for me, too, as I mentioned some posts before.
Could my mp3ad+ script be the reason sfile behaves this way, and if yes, how, if $isalias(sfile) is false and so there's no custom sfile alias? Hundreds of mp3ad+ users don't have this problem. If you want to check the code, you can download my script here: http://mp3ad.markushenn.de/mp3ad+.zip but warning: more than 1000 lines of code. ;-)

Where in your script is $sfile failing? Which line.

Originally Posted By: RoCk

Where in your script is $sfile failing? Which line.

line 932 in mp3ad+ 2.20:

Code:

var %mp3+.exe = $sfile(*.exe,$+(Choose the executable file of your media player))

Nothing special so, and as I mentioned before: every use of $sfile, e.g. via "//echo -a", returns path without filename, too, for those guys.

I'm sure that I've heard/seen that with some HDD, $shortfn will not work, whereas $qt will work
Maybe your issue is not related to what i said but since it happened with only few users, probably that this isn't a mirc problem.

That's not the problem I think. Because the result of $sfile is already wrong, so the $qt identifier would just add some quotation marks around the path. ;-)
But about the $shortfn problem: perhaps the people try to use $shortfn for new (not yet existing) files. This doesn't work! It's only working for existing files.

You misunderstood what i'm trying to explain, i mean that if there is some difference between $qt and $shortfn, maybe mIRC routine for $sfile/$msfile can be improved.

When and where are you using the $isalias(sfile) ?

If you have a local alias in your script file, typing //echo -a $isalias(sfile) in an editbox will return $false. Try this:

Add a new alias within your mp3ad+ script file that is this:

Code:


alias checkit { echo -a $isalias(sfile) }

Then run the /checkit alias.

Also, have that specific person do the same thing. Maybe they somehow added an /sfile alias in their own mIRC. You may want to have that person do a simple find through all of their script files. Make sure you have them tick the "search all files in this section" in the script editor find function. They should search their alias and remotes files.

-genius_at_work

Originally Posted By: RoCk

Thanks to qwerty for my education in evaluation brackets

actually i wrote that article

but ye, the research i did was inspired by qwerty's post <3

edit: oops qwerty didnt notice you there!

edit2: guys, you can't overwrite internal identifiers, so a custom 'sfile' alias wouldn't be the source of the problem :P sounds like a minor fault, ask the guy to post a detailed bug report (windows version etc)

i wonder if he's experiencing problems with any other file access functions

Technically you can:
alias sfile return yes we can!
//echo -a $.sfile(C:\)
//echo -a $/sfile(C:\)
//echo -a $/.sfile(C:\)

But that still wouldnt be the cause in this case :P

Originally Posted By: jaytea

actually i wrote that article

and a fine article it was.

I just got the answer from Stargazer (the last person with this problem). He tried $sfile on a clean mIRC 6.31 install on windows XP SP2 32 bit. The result:
the same (just the path without filename).

how about the nicely misleading //echo -a $sfile

Hehe yeah very misleading indeed, didn't include that because its not the same as overriding a mirc ident that takes params