[RESOLVED] Why use Freefile

[CADman]

Many VB programs I write only require a few files to be opened. I normally just use Open...as #1. Is there any inherent reason why I should use freefile instead?

Cadman

[jmsrickland]

As long as you keep track of them and you are sure that when you use a file number it isn't already in use then no you don't need to use Freefile.

It's mainly for your coding protection and it allows the system to assign a file number that isn't in use.

In your case, no.

In very large programs with many open files I would say yes

[RhinoBull]

Yes, there is a reason to use FreeFile in case file with handle #1 is still open.
If you try to use it again VB will generate runtime error.
On the other hand if you use FreeFile then you can be certain that your program uses available file handle.

However, if you only open 1 file and never another until first is close then it's safe to use #1 [I guess].

[Ellis Dee]

It's a "best practice", much like using Option Explicit.

[CADman]

However, if freefile gives a new handle number while the file is opened (for input only) I expect it will allow a 2nd instance of opening again for input only where I may prefer to have it raise an error to indicate the previous open should have been closed. I assign say #1 for inputing a certain file, #2 for its output and maybe #3 for any other supporting data. So I know then that #1 is my source and it helps to keep track of which file is which and if I do get any error I will know I have not coded the proper error handling of that particular file #.

[jmsrickland]

Instead of Freefile or #1, #2, etc why not use constants

Private Const InputFile = 1
Private Const OutputFile = 2
Private Const SupportFile = 3
etc
etc

Open "file-path\input-file-name" For Input As #InputFile

Open "file-path\output-file-name" For Output As #OutputFile

Instead of getting all mixed up with a lot of different opinions just use the method that you feel most confortable with. It's really up to you.

NOTE

I do a termedous amount of coding and debugging on the fly (during run-time) and in doing so I add many lines just to test so I want to be able to just drop in a variable or such without the concern of having to pre-define everything so I usually do not use Option Explict during this time and I usually use file numbers like #121, 236, 44, 77, 106, etc etc. Mentally I can keep track of these file numbers because they are so far apart in value rather than #1, #2, #3, #4 etc. Later, after I am satified with all the changes I made I will go back and do a clean up to get everything looking nice and neat. But this is me. Someone else will differ.

[CADman]

That is an excellent idea. I just wanted to see if I was missing anything regarding freefile. Of course, not closing a file for input may not damage anything but doing that is bad form/practice. VBforums is terrific, thanks.

[RhinoBull]

That is an excellent idea...

And it probably is. However, using FreeFile is the best one by far.
You can have (if necessary) 3 integer variables and assign value for each with FreeFile instead of hardcoding them.

Regards.

[Ellis Dee]

That doesn't work, Rhino. Calling Freefile three times in a row returns the same number every time. The handle (channel? stream?) is still free until it's used.

[RhinoBull]

I never said "in-a-row" - of course you have to use it:

Private Sub Command1_Click()
Dim inputFile As Integer
Dim outputFile As Integer

    inputFile = FreeFile
    Debug.Print inputFile
    Open "c:\test1.txt" For Input As #inputFile
        '...
        outputFile = FreeFile
        Debug.Print outputFile
        Open "c:\test2.txt" For Output As #outputFile
            '...
        Close #outputFile
    Close #inputFile

End Sub

I've seen projetcs with recursive calls to function that needed to open file(s) but not necessary close when function is completed.
What are you going to do in that kind of situation? Declare const for each possible case?
That's what FreeFile is for - dynamically give you what's available.

[Ellis Dee]

It sounded like you were recommending a variation of the constant approach, using variables instead.

The example you posted goes without saying; of course you have to store freefile's return value to a variable. I don't think I've ever seen anyone use freefile without storing the return value to a variable.

[jmsrickland]

You need to keep in mind that the OP was talking about only a very few files; 1, 2, 3, ,4, maybe 5 at a time. For that, constants are not a bad idea but alot of files....that's another story.

[dilettante]

VB6 "file numbers" are actually like an index into an array of the actual file handles. There is even a slight difference between those returned by FreeFile(0), file numbers 1-255, and FreeFile(1), file numbers 256-511:

file number

Number used in the Open statement to open a file. Use file numbers in the range 1–255, inclusive, for files not accessible to other applications. Use file numbers in the range 256–511 for files accessible from other applications.

Another consideration is that the VB6 Close statement is not synchronous. It takes some time for the final buffer to be written to an output file, and until that write completes VB6 does not actually close the file and release its handle (and thus its file number).

So...

If you process a sequence of files one by one in a loop and use a hard-coded file number it is possible for an exception to be thrown on the second, third, etc. Open using that same file number.

Always use FreeFile() calls to get a file number, just as you should always use Option Explicit as already suggested.

[Lord Orwell]

VB6 "file numbers" are actually like an index into an array of the actual file handles. There is even a slight difference between those returned by FreeFile(0), file numbers 1-255, and FreeFile(1), file numbers 256-511:


Another consideration is that the VB6 Close statement is not synchronous. It takes some time for the final buffer to be written to an output file, and until that write completes VB6 does not actually close the file and release its handle (and thus its file number).

So...

If you process a sequence of files one by one in a loop and use a hard-coded file number it is possible for an exception to be thrown on the second, third, etc. Open using that same file number.

Always use FreeFile() calls to get a file number, just as you should always use Option Explicit as already suggested.

where did you find your information on the asynchronous nature of the close?

[anhn]

Another consideration is that the VB6 Close statement is not synchronous. It takes some time for the final buffer to be written to an output file, and until that write completes VB6 does not actually close the file and release its handle (and thus its file number).

Agree that the Close statement takes some time to finish but I have the same question as Lord Orwell.
In sequencial processing, perhaps the next line of code will not be executed until the Close statement is finished.

[lmstearn]

where did you find your information on the asynchronous nature of the close?

(In gardening there's dead heading- just honing these skills in dead threading):
The logs in Process Monitor show how these events are generated through time.

Came to this thread because of calling FreeFile without the brackets. Oops.