!include FILE_IO.INC
FOPEN file O_RDONLY "input.dat"
if_false
print "\r\n\r\nnError Loading Configuration File - Input.Dat"
return
end_if
FOPEN file O_CREAT|O_TRUNC "output.dat"
if_false
print "\r\n\r\nnError Loading Configuration File - Output.Dat"
fclose Input.dat"
return
print "\r\n\r\nnDue to file error(s) All files closed at this time."
end_if
!include FILE_IO.INC
FOPEN file O_RDONLY "input.dat"
if_false
print "\r\n\r\nnError Loading Configuration File - Input.Dat"
return
end_if
FOPEN file O_CREAT|O_TRUNC "output.dat"
if_false
print "\r\n\r\nnError Loading Configuration File - Output.Dat"
fclose Input.dat"
return
print "\r\n\r\nnDue to file error(s) All files closed at this time."
end_if
end
PistolGrip wrote to Finnigann <=-^^^^
RE: HW 100.2
BY: Finnigann to All on Tue Oct 23 2001 10:20 pm
!include FILE_IO.INC
FOPEN file O_RDONLY "input.dat"
if_false
print "\r\n\r\nnError Loading Configuration File - Input.Dat"
return
end_if
### Everything is fine until the next line. There, you try to open a second ### file with the same <filehandle> "file" as the input file.
You should try ### to use unique filehandles, especially if you need to open mulitple files.
FOPEN file O_CREAT|O_TRUNC "output.dat"
if_false
print "\r\n\r\nnError Loading Configuration File - Output.Dat"
### There is also an error on the next line. You are trying to close a ### filename, and not the <filehandle> (ie. file) as fclose function requires.
fclose Input.dat"
return
print "\r\n\r\nnDue to file error(s) All files closed at this time."
end_if
Not Bad, "B" :)
Amcleod wrote to Finnigann <=-
Secondly, your code executes a RETURN which is followed by a PRINT.
The PRINT is what is called "unreachable code". You never get to do
the PRINT because you always RETURN just before you get to the PRINT.
Some compilers will warn you about "unreachable code", but I don't know
if BAJA.EXE does.
What you need to do is put the PRINT first and _then_ the RETURN.
Keep it up! Work on the other steps now...
Question: On naming internal file handles, is there a character limit?
ie: no spaces or other characters forbidden. I guess periods and either slash mark or an astricks or question mark or out of bounds too?
So the 'file' is the handle that BAJA see it as... A varible, assigned in the act of opening the input.dat. I need to refer to THAT varible when manipulating INPUT.DAT ('file' was prolly a bad choice in that case).
Maybe something descriptive would have been a better choice. Like 'Player_list' or 'Game_scores'
Question: On naming internal file handles, is there a character limit?
ie: no spaces or other characters forbidden. I guess periods and either slash mark or an astricks or question mark or out of bounds too?
Not Bad, "B" :)
Actually it's YOUR B as I cut and pasted heavily from your example.
So the 'file' is the handle that BAJA see it as... A varible, assigned in the act of opening the input.dat. I need to refer to THAT varible when manipulating INPUT.DAT ('file' was prolly a bad choice in that case).
Maybe something descriptive would have been a better choice. Like 'Player_list' or 'Game_scores'
A gray sliver of light...
Digital Man wrote to Finnigann <=-
RE: HW 100.2
BY: Finnigann to Amcleod on Wed Oct 24 2001 02:46 pm
Question: On naming internal file handles, is there a character limit?
ie: no spaces or other characters forbidden. I guess periods and either slash mark or an astricks or question mark or out of bounds too?
Answer (from http://synchro.net/docs/baja.html#Variables):
Variable names are not case sensitive and must begin with an alphabetic
character or an underscore (_). Variable names can be any
length and
may contain alpha, numeric, and underscore characters only. The
variable name "str" is reserved to represent the current
command string
and should not be used as a user defined variable name.
RE: HW 100.2
BY: Finnigann to Amcleod on Wed Oct 24 2001 02:46 pm
Question: On naming internal file handles, is there a character limit? ie: no spaces or other characters forbidden. I guess periods and either slash mark or an astricks or question mark or out of bounds too?
In BAJA the file handle is just a common integer, so the naming conventions exactly the same as for integers.
Don't try doing arithmetic with file handles! :) The arithmetic will work fine, but the files themselves are likely to go to hell very shortly thereafter!
Don't try doing arithmetic with file handles! :) The arithmetic will wo fine, but the files themselves are likely to go to hell very shortly thereafter!
What, exactly, _WOULD_ happen if you _did_ do arithmetic with file handles?
RE: HW 100.2
BY: Prime to Amcleod on Tue Sep 19 2000 07:31 am
Don't try doing arithmetic with file handles! :) The arithmetic will fine, but the files themselves are likely to go to hell very shortly thereafter!
What, exactly, _WOULD_ happen if you _did_ do arithmetic with file handle
Well, handles are just integers, and they can be just about anything. for instance they may represent integer indexes into a table of file-control-blo so if you added your third and fifth handles you would get the handle of som file furthur up the table -- possibkly one never opened -- and the results accessing that file would be (most likely) a dismal failure with interesting side-effects. Possibly the the handle is the actuall _address_ of the FCB a so monkeying with them could give a pointer into some random part of memory which would again, give interesting and unpredictable side effects if you tr to use it.
You can probably experiment safely with _writing_ the file handle to the console. Open three or four files and print the file handles as integers. may get a series of integers like 3, 4, 5, 6 for the four filehandles. SO y add two to the first file handle and it suddenly becomes the third filehandle...
\/s
Just a thought, but shouldn't there be some mechinism to prevent the acciden adding of file handles?
Just a thought, but shouldn't there be some mechinism to prevent the acciden adding of file handles?
Sysop: | Tandy |
---|---|
Location: | New York, USA |
Users: | 15 |
Nodes: | 13 (0 / 13) |
Uptime: | 65:07:51 |
Calls: | 335 |
Messages: | 113,199 |