I think it would be quite useful to have a $run identifier, which would return $true/$false depending on if mirc can /run a file or url.
For example:
if ($run(notepad)) { run notepad }
Rather than using $isfile or $exists (which wouldn't work on 'notepad' anyway) - this identifier would only see if $1 could be /run
I hope my point is being made and maybe someone will agree with me
Thanks for the word,
antisocial
Well how does mIRC determine if it can be run?
if a file is locked for example. it cannot be run, mirc could then say blah is locked and cannot be run.
Quite right but that isn't the issue. mIRC can't know of the opposite being true until the application is running so you can't get a result until the programme starts.
Look at it in this light: You pick up the phone and ring me - you don't know I am going to answer the call until I actually pick up the handset.
maybe give it a timer then. say like, if its not open in 5 seconds, return $false
But then that means $run has to actually run the command to see if it works, which is almost cetainly not what the user wanted.
try to access the file, if it starts to load, then cancel the opening of it and return $true
What would this function actually be useful for? What did you want to do with it?
Thats not even what I meant, what happens if I specify a file that isn't executable?
$run(README) for example
How is mIRC to know that that file can't be run?
It will open, it's a file, any file can be opened. If it couldn't be opened, then there would be no way to view a README in notepad for example. There is no IsFileExecutable() function in Windows.
Umm apparently you have no idea what a locked file is, it has nothing to do with a password. A locked file is when you get the "can not open, this file is in use by another application" error.
From Microsoft:
"The LockFile function locks a region in an open file. Locking a region prevents other processes from accessing the region."
I don't see any mention of a password there, do you?
And that doesn't have anything to do with what I said:
codemastr: phoenix, why is the sky blue?
phoenix: some cars are blue.
You didn't address anything I stated, you simply wrote some gibberish.
That isn't what the poster wanted though. I think he wanted an alternative to $isfile and $exists. He gave the example of 'notepad'. If notepad doesn't exist on the users system they will get an error message:
* /run: unable to open 'notepad'
I believe this suggestion is aimed at avoiding error messages like that.
Ofcourse there is no API way of doing this. However, with a little thought, It is possible that mIRC could check the registry and see if 'notepad' is registered, in the case of no filepath being specified. And then return $true or $false.
It's also possible that mIRC could perform the operation of $isfile internally and return $true or $false, when a filepath is specified.
There may also be a way to determine if a user has access to that file under NT, and return $true or $false.
--
A more general method of handling all mIRC error messages would be preferable to me though (ON MERROR).
Well if that doesn't make sense, yell at Microsoft, they are the ones who decided a "locked" file has nothing to do with a password. A file that needs a password to be opened (depending on some conditions) is either "password protected" or "encrypted" NOT locked. It's not my fault you don't understand FileSystem terminology.
*sigh* whatever, you're wrong, you just don't want to admit it.
But regardless, thats not what the original poster, or I were talking about. I said what happens if you want to determine if a file such as "README" is run-able? How can you determine if it is? The answer is, you really can't.
i know, i admit it im wrong, and i shouldnt of posted in the 1st place.
Actually, I agree with saxon and there are ways to determine if /run can execute a file before it actually executes the file with ShellExecute.
First you'd check the system PATH to see if the file can be found ($ispath would be cool). If a file is located then trace the file extension through the registry to see if it's associated with an application or not (I believe an API exists for this even). Then you would test if the file is locked by the system by attempting to OPEN the file (doesn't have to physically read it, just requests permission to access it). If the OPEN fails, then /run is certain to fail aswell.
Granted, it would be impossible to cover all possible errors... eg: WinZip Error "File Appears Corrupt", could not possibly be anticipated... but the file still successfully /ran, and that's all that $run needs to do.
- Raccoon
Association does not imply execution. For example, I have an association setup for .a23 files, however all the association does is make it so an icon is displayed for a23 files, if I click the file I get the standard "select a program" dialog box. File associations do not determine whether a file can be executed. And opening a file doesn't test a lock. I can lock bytes 23 through 29. Opening it will succeed, however when I try to read bytes 23 through 29 that will fail.
Files which are only associated for an icon don't have a 'command' folder with a value pointing to an application or reference. This is an obvious distinction that would be looked for.
files that are locked surely have some way to test for this regardless of what parts are locked.
- Raccoon
From MSDN
GetBinaryType
The GetBinaryType function determines whether a file is executable, and if so, what type of executable file it is. That last property determines which subsystem an executable file runs under
BOOL GetBinaryType(
LPCTSTR lpApplicationName,
LPDWORD lpBinaryType
);
Wouldnt this be exactly what you want the $run identifier to do?
Yep.
And any other "if file cannot be accessed" checks that might be possible.