Forums Bug Reports $fopen(name)

; close file if already open in mirc..
if ($fopen(bleh)) .fclose bleh

* Invalid parameters: $fopen (line 16, fa.mrc)

that's the bug...

I wasn't able to reproduce this. I did '/fopen bleh versions.txt' then '//if ($fopen(bleh)) fclose bleh' and got '* fclose closed 'bleh' (C:\mirc\versions.txt)'.

Maybe your problem is that 'bleh' is not a valid file handle?

mIRC should return $null if the file handle isn't in use, not halt the script with an error - which is the whole point of visionz example, he/she wants to check if the file handle is in use, and if so close it.

The only 'safe' way to check if a file handle is in use would be by looping thru $fopen(N) - and even that has problems (//echo -a $fopen(1) without any handles open produces the same error - so scripts would have to check $fopen(0) first before looping through).

Given the behaviour of other identifiers this is surely a bug.

The better way to fix this is to redo the routine in which this behavior is needed. You shouldn't have to keep a file open for more than a single routine (eg, alias or event). If the data-source needs to stay open for a long time, you will be better off using some kind of memory storage (hash tables..) and then writing the data to disk when that duration is over.

Basically, what I'm saying is you shouldn't have to need to check $fopen(blah) for the validity of a file-handle. You should already know if it's valid or not, because you checked $ferr after you called /fopen.

Thank you Skip, I see what the problem is now and I agree, it's a bug.

Well consider this. I just wrote a socket program that allows people to store files on my machine (some kinda file transfer thing). I've used the new file managment stuff for this. Now, seeing as how multiple transfers could be opened at once, I need to name the files something random, so I do /fopen $rand(1,4837483) thefile.txt

Well what happens if $rand(1,4837483) returns the same thing twice? /fopen will fail because it is already open. The solution would be.

var %r = $rand(1,4837483)
while ($fopen(%r)) {
%r = $rand(1,4837483)
}

That would ensure that I'd never be trying to reuse a name that already exists. I mean, this works fine for every other mIRC identifier I know of. $sock(hsjfdssad) will return $null if it doesn't exist, $hget(hsdsfdsf) returns $null if it doesn't exist, and I'm sure there are others. I don't see why this identifier should work differently than all other identifiers, especially when that limits it's usefulness.

Your code is bordering on trick-programming. There are ways to get around it, like incrementing a global variable after a file is opened, thereby ensuring that you would never use the same one twice. Its usefulness is not limited in any way I can see. Maybe "its ability to write really small code" is.

I wasn't arguing whether or not it should return $null. I don't care if it does. All I was saying was it looked like to me that the guy in the first example was trying to close a file he didn't know if he ever opened, like a failsafe procedure. You shouldn't have to do that, because you should know if you ever opened it. And if a situation arises where you can't use conventional methods, like checking $ferr a few lines previous in the code, well, the new design to fix it falls upon you, not Khaled.