cripster wrote:Hello, and thanks for this forum! This question concerns QBX 7.1 and the LINE INPUT # statement. Quite simply, is there a size limit on the file QBX is trying to input from? I am trying to access a text file and as soon as the file is opened an ILLEGAL FUNCTION CALL error occurs. I played around with the size of the sourcefile and QBX will only run if the source file size is less than 32767 bytes......
I'm referring to QuickBasic, which should be the same as for QBX.
The ILLEGAL FUNCTION CALL is not an error directly related to the LINE INPUT # statement, it refers to the fact that no string in QB can be greater than 32767 bytes in length, period.
Wow, what kind of a file do you have? LINE INPUT # is for reading records from a sequential file. Do you have a sequential file with records greater that 32767 bytes? I really doubt it.
Note that for QB, sequential files have records terminated by a carriage return and line feed (CRLF).
Perhaps you're trying to read some other kind of file, like a .EXE file or other binary type file. Since these types of files are not organized by records terminated by a CRLF, it is very likely that you will try to input more than 32767 bytes without encountering a CRLF.
Or maybe you're trying to read a text file created by a UNIX based program. These can end in CR only, LF only and other combinations.
Possible solutions:
1) If the file has records ending in CRLF but are longer than 32767, then you might try to use a text editor to cut down the size of the records before using the file in your program.
2) If the file is any binary type file, then you must open the file for binary and read it in chunks using the GET statement.
3) If the file comes from UNIX, or something similar, with records terminiated by other than CRLF only, then you need to find a text editor or utility that will read the file and write it back out with records terminated by CRLF only.
You could also read this UNIX type file as binary in chunks, and have your
program figure out where each record ends. This can get tedious.
Why don't you tell us where this file comes from, what type of system, what type of records it contains, are the records fixed or variable in length, are they ASCII characters or are they binary, etc.
If you're not really sure what's on this file, I suggest browsing the file with a hex editor. If you don't have one, you should try to get one.
*****