How can I close this file (and only this one)?

General FreeBASIC programming questions.
jevans4949
Posts: 1186
Joined: May 08, 2006 21:58
Location: Crewe, England

Re: How can I close this file (and only this one)?

Post by jevans4949 »

@Tourist Trap: Is there a reason you can't use a global variable to store the file number you used?

If it's the case that your program is going to be opening files in an unpredictable way, there are a number of ways of dealing with this. Perhaps you could clarify?
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: How can I close this file (and only this one)?

Post by Tourist Trap »

jevans4949 wrote:@Tourist Trap: Is there a reason you can't use a global variable to store the file number you used?

If it's the case that your program is going to be opening files in an unpredictable way, there are a number of ways of dealing with this. Perhaps you could clarify?
In fact I'm just pointing out the fact that the things are done presently so that we need very rigid behaviour to deal with files. But in another hand, this is not engraved in the marble of the compiler. It seems so that something is lacking somewhere for all this to keep always under perfect control, and comfortable for the user. But I don't really know what and where.
For my part for modularization reason I tend to avoid any global variable as a principle. So I would be a little disappointed to have to use some here...
noop wrote: So you could open 10 files in a row and get the file numbers 1 to 10.
Yes you're right, multithreading could cause some trouble for instance. Do you know how to access this array you are mentionning that keeps track of handles?
noop
Posts: 130
Joined: Sep 18, 2006 10:29

Re: How can I close this file (and only this one)?

Post by noop »

Tourist Trap wrote:
jevans4949 wrote:@Tourist Trap: Is there a reason you can't use a global variable to store the file number you used?

If it's the case that your program is going to be opening files in an unpredictable way, there are a number of ways of dealing with this. Perhaps you could clarify?
In fact I'm just pointing out the fact that the things are done presently so that we need very rigid behaviour to deal with files. But in another hand, this is not engraved in the marble of the compiler. It seems so that something is lacking somewhere for all this to keep always under perfect control, and comfortable for the user. But I don't really know what and where.
For my part for modularization reason I tend to avoid any global variable as a principle. So I would be a little disappointed to have to use some here...
I would generally agree. FB.Image handles this nicely. You don't need to store the width and height of the image. But, obviously, you will have to store the pointer to the image.
Here, we have to store a "pointer" (not a memory pointer) to a file handle. You can't get around that. How do you want to access the file otherwise? Just as you have to store the image pointer in order access/use the image. And if you lose the pointer, you cannot free the memory / close the file anymore.
Tourist Trap wrote:
noop wrote: So you could open 10 files in a row and get the file numbers 1 to 10.
Yes you're right, multithreading could cause some trouble for instance. Do you know how to access this array you are mentionning that keeps track of handles?
No, unfortunately I don't. I would imagine that it's easy to expose the array by changing fbc's sourcecode.
But what do you gain from that? You then have a list of all open file handles. You could also get them by iterating through all numbers:

Code: Select all

open "c:\windows\notepad.exe" for input as #123

for i as long = 1 to 255
    if open("" for input as #i) = 1 then
        print "open file: ";str(i)
    end if
next i
sleep
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: How can I close this file (and only this one)?

Post by Tourist Trap »

noop wrote:Here, we have to store a "pointer" (not a memory pointer) to a file handle. You can't get around that. How do you want to access the file otherwise?
By filename. The main use of filenum handle is to provide a convenient shortcut, and also to manage not overflooding beyond 256 open handle at the same time.
noop wrote: You could also get them by iterating through all numbers:

Code: Select all

open "c:\windows\notepad.exe" for input as #123
for i as long = 1 to 255
    if open("" for input as #i) = 1 then
        print "open file: ";str(i)
    end if
next i
sleep
Good idea. To be more precise however, the problem is that we have only one global familly of handles. So even if we write our own logic embedded in a file management udt, some additionnal dependancy may open/close handles already used. It's a little like randomize. You can want to get strict control on it, but if a dependancy throws a radomize here and there, you can't forbid it and it is proved to change (most of time slightly) your random numbers list characteristics.
So I see only two easy things that could make life easier, the first is a function that would expose the currently alive handles with what filename they are associated to. The second, the ability to get another channel of independent handles. For instance allowing some syntax like Freefile(chan1).
Having a more local Open keyword that would create handles that are destroyed automatically at any subroutine or function exiting, could also save some management. When a file is not closed, the shell/os commands on files can't be executed.
Post Reply