FreeFile

[figler]

What are the disadvantages to referring to a file by an actual number instead of using FreeFile and storing the result in a variable that I then use to refer to the text file?

I encountered a problem appending to a text file that may have been fixed by getting rid of my FreeFile variable and using the number "1"...

This is the code:
FileNum = FreeFile
Open App.Path & "\EXAMPLE.log" For Append Shared As #FileNum
Print #FileNum, "THIS IS WHAT I PRINT"
Close #FileNum

For some reason, an error is raised now on the line beginning with "Open" (55: "File is already open.&quot. I don't know how this could happen, since the lock-type is "Shared." Anyway, I opened up the immediate window at this point and typed "Close 1" (at this point, both FileNum and FreeFile were equal to 2). After this, ?FreeFile returned 1 (which kind of makes sense -- but this isn't what i'm interested in).

What is weird is that I had completely lost a handle on the original file that was *somehow* still open. In a case like this I would want the error-handling code to do:
If err.number = 55 Then
Close FileNum
Resume
'then i should be able to open the file like normal
Else
'other stuff (probably exit sub)
End If

But obviously this won't work since FileNum is (inherently -- since FreeFile wouldn't have grabbed a file that was 'already open') not the same as the number for the file that is already open.

So here are my questions:
Is it bad to use an actual number to refer to that file? As long as I don't do any other file writing in my app I should be fine, eh?
If I do use FreeFile, how do I deal with errornum 55???

Thanks again, guys&gals for your help. -Brad

ps Any idea how the file didn't close in the first place?

 

[JohnYingling]

This has happened to me when I stepped through the code and ended before executing the Close. Exiting and restarting the VB IDE usually cleared it up. "End" is bad in VB6, even in Debug Mode. I stick with Freefile.

http://www.VBResizer.com

Generate Forms/Controls Resizing/Tabbing Class

http://www.VBCompare.com

Compare Code (Text)

http://www.VBSortGen.com

Generate Sort Class in VB or VBScript

 

[figler]

Hmmm, well I do use 'End' once in my code -- when my database object is unable to make a connection, I display the error, display my own error and then 'End'. Is that a bad idea? Is there a safe way to 'End' given that I want to avoid the aforementioned error at all costs?

 

[JohnYingling]

I just never use End in the application.
This is from the VB Reference on MSDN CD October 2001
"Note The End statement stops code execution abruptly, without invoking the Unload, QueryUnload, or Terminate event, or any other Visual Basic code. Code you have placed in the Unload, QueryUnload, and Terminate events of forms and class modules is not executed. Objects created from class modules are destroyed, files opened using the Open statement are closed, and memory used by your program is freed. Object references held by other programs are invalidated.

The End statement provides a way to force your program to halt. For normal termination of a Visual Basic program, you should unload all forms. Your program closes as soon as there are no other programs holding references to objects created from your public class modules and no code executing."

http://www.VBResizer.com

Generate Forms/Controls Resizing/Tabbing Class

http://www.VBCompare.com

Compare Code (Text)

http://www.VBSortGen.com

Generate Sort Class in VB or VBScript

 

[figler]

Yah, I realized when I tried to delete the executable and got a 'permission denied: file may be in use' error that 'End' is a pretty bad idea. I just wish there was some middle ground -- a way to step out of every nested procedure that I am in and go straight to a clean close of the application. Possible?