Checking For Existing File

[ViperInc]

Hi
Im faily new to the VB coding and was just wondering how to make the program check for files that are installed.

i thought the 'if' statement migth work
but doesnt seem to
here the code i wrote...

Sub Form_Load()
If "C:\Windows\System\c32.dll" Then
cmdDivx.Visible = False
Else
cmdDivx.Visible = True
End If
If "C:\Windows\System\sound.dll" Then
cmdaudio.visible = false
Else
cmdaudio.visible = true
End If
End Sub
if it works this way when the user runs the program he wont accidently install the drivers again...

any ideas???

 

[RobertP]

You need to use the dir command. For example:

dir("C:\Windows\system\sound.dll&quot

would return "sound.dll" if it was found or "" if it wasn't.

Hope this helps,

Rob.

 

[everytime]

You can also check out using a FileSystemObject Object which gives you many methods to use on files, folders and drives

Matt.

 

[jmarler]

use this . . .


if Len(Trim$(dir$("C:\Windows\system\sound.dll&quot)) > 0 then
'** File exists
else
'** File does not exist
end if



Note
I know that it look odd to see the Len and the Trim commands there when you are just checking for a string, but it is about 4 times faster to just check the length of the string rather than checking the string name itself. This is due to theway VB6 handles strings . . . if you don't believe it, try some timing tests.
Also, be sure to use the $ on your dir command (and other strings) . . . this will force VB to use string variables rather than variants . . . this will be about 3 times faster.
- Jeff Marler

http://www.JeffMarler.com

(please note, that the page is under construction)

 

[rvBasic]

The question has been answered lots of time in this forum: check e.g. thread222-31190, thread222-40467, thread222-54723, ...

My favorite methods goes with everytime's suggestion: use the FileSystemObject

Dim objFso as FileSystemObject
Set objFso = New FileSystemObject
Select Case objFso.FileExists(strFileName)
Case True
'File Exists Processing
Case False
'File does not exist Processing
End Select
Set objFso = Nothing

The Fso should be included into your program through the Project Menu -> References -> Add Scripting Runtime Library.

Fso will be slower(?) than some other methods, essentially due to the overhead of instantiating the Fso. But this is done only once: most times you can afford this.

At least your program is readable: it answers what you askFileExists _________________________________
In theory, there is no difference between theory and practice. In practice, there is. [attributed to Yogi Berra]

 

[jmarler]

rvBasic, the FileSystemObject is a nice way to do it, but why take the time (and memory and the extra library reference) to instantiate an object just to check if a file exists when standard VB commands will do the same thing? I could see creating the object if you were going to do more with it, but not just to see if a file exist. - Jeff Marler

http://www.JeffMarler.com

(please note, that the page is under construction)

 

[ViperInc]

Thanx jmarler
it work great now!!!!

thanx heaps

 

[rvBasic]

Jeff you're right: if I only have to check if a file exists, then I would hesitate(?) to use the FSO. But you rarely perform this check and then continue your program without any further File operations, all of which can be done by the same FSO object.

I especially like the very English wording of the FSO syntax: they tremendously improve program readability.

Yes, the FSO has its limitations: file i/o is limited to text files and it's slower (about 30%) than the traditional methods. Most people accept this penalty for data bases. Why not for traditional files?

So basically you make a decision about performance vs future maintenance. I do care about performance, but time and again history has proved that the systems themselves catch up with performance. The same unfortunately can't be said for maintenance.

A last (unconvincing) argument: I fear that the DOS-style commands are so old, that they are bound to disappear. May be in the next .NET version?

Take care,
Robert

_________________________________
In theory, there is no difference between theory and practice. In practice, there is. [attributed to Yogi Berra]

 

[jmarler]

Robert,
You do make a very good point about older commands going away and not being supported by future version. This is very true with .NET . . . I have .Net (beta1) installed and it is very different (but really cool) when compared to the current VB. The problem with this is that you can never be sure of what will be supported in the future . . . but then again, this can be said for any function/method in any language. At the moment, however, I have not heard any talk indicating that "DOS-style" VB commands (such as Dir) are going away. Of course, if you really wanted to be safe in this regard, you would be using the core OS APIs.
Also, I would agree that the English wording of the FSO syntax makes it very easy to use, but I do have to disagree with you when you said, "I do care about performance, but time and again history has proved that the systems themselves catch up with performance." Once again, what you said is 100% true . . . systems are getting faster everyday and memory is getting cheaper as well . . . However, I don't think that this should be an excuse for programmers to not write efficient code I've seen too many developers (and please, don't feel that I'm accusing you of anything, because I'm not) write horrendous code that is slow and a hog for memory with the excuse . . . the system has more than enough speed and memory to deal with this. Here is an (extreme) example of what I mean . . . at my last job (an insurance company), the application that was written and in production had a section where it took processors over 25 minutes to run a function that copied part of the policy. This section actually passed QA/QC. The developers who wrote it said that it could not be done any faster and used the excuse that the systems will eventually catch up with the performance. I rewrote the section using several optimization techniques and the new code (running on the same computer with the same data) ran the copy function in under 45 seconds . . .
OK, I've said enough on this . . . I just wanted to respond to some of you comments. - Jeff Marler

http://www.JeffMarler.com

(please note, that the page is under construction)

 

[bnet]

using FileSystemObject gives a virus alert if used on a system having Norton Antivirus (NAV) installed. I have not tried with other Anti-virus softwares as yet.

this i believe is due to Script-blocking option of NAV as most of the email viruses call FileSystemObject to get disk drive/folder/file information.

therefore, i wud prefer non-fso solution to this problem.

Thanks.

 

[strongm]

Oh for goodness sake. Are you going to search for every ancient thread that mentions FSo, and then damn it out of hand?