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
Printable View
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
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
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].
It's a "best practice", much like using Option Explicit.
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 #.
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.
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.
And it probably is. However, using FreeFile is the best one by far. ;)Quote:
Originally Posted by CADman
You can have (if necessary) 3 integer variables and assign value for each with FreeFile instead of hardcoding them.
Regards.
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.
I never said "in-a-row" - of course you have to use it:
I've seen projetcs with recursive calls to function that needed to open file(s) but not necessary close when function is completed.Code: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
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.
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.
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.
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).Quote:
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.
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?Quote:
Originally Posted by dilettante
Agree that the Close statement takes some time to finish but I have the same question as Lord Orwell.Quote:
Originally Posted by dilettante
In sequencial processing, perhaps the next line of code will not be executed until the Close statement is finished.
(In gardening there's dead heading- just honing these skills in dead threading):Quote:
Originally Posted by Lord Orwell
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. :eek: