Open syntax -> what is the function result type?

[MrSwiss]

There is more on File Handles:
e.g. we have an open File with #1 (for append), but now we also want to copy the #1 content to another
location ... we can, "via OS" force a second Handle to the same File (that has already #1), however I'm
not certain that FB can manage this (OS Commands like "copy" use this technique, a temporary second
Handle on the same File).

It is exactly under such conditions, where the additional File stuff (Lock/Unlock etc.) comes in handy, to
keep Control over the File's processing, e.g. who has which Permissions such as: read, write, read/write.

[Tourist Trap]

however I'm
not certain that FB can manage this (OS Commands like "copy" use this technique, a temporary second
Handle on the same File).

All the question is to have a good page in the doc that would explain the right way to use files in the fb philosophy. There are already two ways, via "OPEN", and via "shell/os" fb commands. But they can conflict:

Code: Select all

open "aaaaaa.aaaaaaa" for output as #1
name "aaaaaa.aaaaaaa", "bbbb.bbbb"        '-----> crash

And maybe, as you signal here could be also a pure OS api call, via Shell command maybe. I think I'll test a rename with a Shell call to see if the crash remains.

Code: Select all

open "aaaaaa.aaaaaaa" for output as #1

'name "aaaaaa.aaaaaaa", "bbbb.bbbb" 
shell ("rename " & "aaaaaa.aaaaaaa" & " " & "bbbb.bbbb")

sleep
end 0

Ok that doesn't rename, but there is a very nice error message.

[MrSwiss]

But they can conflict:

Code: Select all

open "aaaaaa.aaaaaaa" for output as #1
name "aaaaaa.aaaaaaa", "bbbb.bbbb"        '-----> crash

... via Shell command maybe. I think I'll test a rename with a Shell call to see if the crash remains.

You don't have to test that: it won't work!
Not a Crash, but an Error Message.

[Tourist Trap]

You don't have to test that: it won't work!

If it doesn't crash, it works. The important thing is to get an error message. Fortunaltely this is what happens. So I tend now to think that the crash triggered by name()'s call is more a bug.

[MrSwiss]

the crash triggered by name()'s call is more a bug

Well, not really ... if you check first, if the File is "closed".

[Tourist Trap]

Well, not really ... if you check first, if the File is "closed".

That's what fxm showed in the other topic. But for instance Kill() triggers an error in this case. So there is something here not consistent. Whatever, the documentation doesn't seem to warn about this issue.

But your remark remains important because there is no really any official way to check if a file is currently in use via "Open". Unless testing with trying a kill, which is rather radical.

[MrSwiss]

Unless testing with trying a kill, which is rather radical.

There are at least workaround's possible. Remember my Idea of using a Type to keep track of Files "open" ...
Just for "proof of Concept" I've coded a short hack on that.
But I think that Code in this Section is not a very good Idea, just let me tell you: it works!

[Tourist Trap]

There are at least workaround's possible. Remember my Idea of using a Type to keep track of Files "open" ...
Just for "proof of Concept" I've coded a short hack on that.
But I think that Code in this Section is not a very good Idea, just let me tell you: it works!

You can post it in tips and tricks. The code has no to be big. I still don't see an easy workaround for the moment.

[Tourist Trap]

@fxm,

sorry for making so much remarks in a so little amount of time, but other thing I find not obvious right now. The file handle (filenum) obtained by an Open call is apparently global. If I open a file and get it associated with a filenum, this value seems to go beyond any scope.

For instance it goes out of a function block. One may think that a file handled created in a block is released (Close being called automatically) when going out of scope.

So my question is, is that always true that the file handle generated knows no scope limit? Or is there some cases where Close is called automatically?

[MrSwiss]

You can post it in tips and tricks.

Done, see Link below ...

File "open" UDT

[fxm]

New remark. The Open function mentions its relation with Err() function :

The error code returned by Open can be checked using Err in the next line.

Unfortunately, (some) other functions that can have there error return code checked by Err() omit this useful warning. For instance in the Kill() documentation page, it seems to be the case, but it's not mentionned. For Kill it's really important because the page explains that the Kill may fail or not in a rather unpredictable way (OS dependent)

Yes, that's probably true for a number of cases.
True at first sight for Bload(), Bsave(), Close(), Filecopy(), Getjoystick(), Getmouse(), Imagecreate(), Imageinfo(), Kill(), Open [...], Screenres(), Setdate(), Setmouse(), Settime(), Screensync().
I have to check all that before updating the documentation.

Documentation updated for the 20 keywords above.
I have not tested systematically all keywords having a function version but only those I thought to can do this:

• The error code returned can also be checked using Err().

[Tourist Trap]

Documentation updated for the 20 keywords above.
I have not tested systematically all keywords having a function version but only those I thought to can do this:

• The error code returned can also be checked using Err().

Thank you for those updates. This is maybe sufficent to make the user aware of this feature. If I have time some day I think I'll try to make a list of the functions that return an error stored in to the Err() buffer (I mean something that could be listed at the Err() page rather than at every keywords that use the feature).

Other thing. FileCopy gives this precious hint:

This file will be overwritten if it exists. This file should not be currently referenced by any open file handles.

Is there any case where a function of the FILE category doesn't follow this rule?

[fxm]

This file should not be currently referenced by any open file handles.

I think there is no risk that the program crashes and that this is only an advice for FileCopy in order to avoid overwriting a file already open for other processing.
For the other commands FileXyz, there is no risk because they return only information on the file.

[Tourist Trap]

I don't know if this image (ugly..) is true.