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.
Is there a way around this? I am not new to programming, but not very good at it either (learned BASIC on a TRS80 Model I Level II computer, and still need to use LINE NUMBERS to keep things straight in the ol' noggin!)
Any and all responses are appreciated, but please remember that I am not an advanced programmer.
Thanks for any and all help!
Line Input Limitation?
Line Input Limitation?
cripster
quizzical quad
quizzical quad
RayBritton wrote:can you post your code please
Sure. Here it is:
Code: Select all
10 CLS
100 OPEN "c:\upt3a.log" FOR INPUT AS #1
140 LINE INPUT #1, l$: PRINT l$: l$ = ""
160 IF EOF(1) = -1 THEN GOTO 220
200 GOTO 140
220 CLOSE : END
cripster
quizzical quad
quizzical quad
Re: Line Input Limitation?
I'm referring to QuickBasic, which should be the same as for QBX.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......
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.
*****
Re: Line Input Limitation?
Wouldn't have a clue about how to read the UNIX type file in chunks!moneo wrote: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......Looks like you've hit the nail on the head! Problem is, I don't really know what type of file this is. I agreed to do some beta testing for an anti-virus company, and this file is a log generated by the engine of their new build. In previous builds I'm sure the log file was in ASCII, and could easily be edited with a text editor (I use Ultra Edit). When opening the current log file, Ultra Edit comes up in Hex mode. If I toggle out of Hex mode, the file looks like this: *Note---I've replaced the characters in the file and pathnames with ? marks (which is what I'm trying to write the BASIC program to do)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.
This file has to be generated and sent to them regularly. The anti-virus company doesn't need file or foldernames unless there's a problem (I checked), but they are interested in the other log data.Code: Select all
2006-07-11 20:31:15:921 File Name: ?:\??\????????\????.??? ? : \ ? ? \ ? ? ? ? ? ? ? ? \ ? ? ? ? . ? ? ? Elapsed Time: 937500 (100 ns) File Size: 288768 (bytes) Pattern Used: Inst Count: 0 Virus Found:
What I am trying to do is:
Open file1 for input
Open file2 for output
Input line$ from file1
If line$ contains a \ character, jump to line parsing subroutine
If line$ has no \ character, output line$ to file2, get new line$ from file1
It sounds fairly straightforward, but apparently this is not a text file, so...
Upon reading the above, I took another look at the file with Ultra Edit in Hex mode. Each line is terminated with Hex 0A (LF). I then searched for Hex 0D (CR). There were none! Did a global search for 0A, replaced it with 0D0A (there were >16000 of them) then saved it as a different filename. The QBX program now seems to get through the file from beginning to end. I am currently outputting to screen only, but it scrolls by so fast it's hard to see what's happening. I'll have to add a small routine to 1) pause the output, and 2) break out of the program so it won't be necessary to watch it scroll through the whole 500k!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.
Looks as if 3) is what I'm dealing with, and Ultra Edit seems to be able to do Hex editing 'cuz at least the file is scrolling through now.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.
I am also concerned about the "spaces" on line 3 of the Code section above. Ultra Edit shows they are Hex 00. Not sure if they are going to mess things up later on.
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.
Again, it's a log file created by an updated anti-virus scan engine I am involved in beta testing.
Sorry for being so long-winded. Am just trying to be thorough.
Thank you so very much for your post, and for helping to diagnose the original problem. I truly appreciate it!
cripster
quizzical quad
quizzical quad
You're right, it looks like you have a file generated by some Unix type program. Here's a piece of the documentation for a conversion program that I wrote having the same problem:
Assuming the file only has records terminated by a LF, like you said, you still will need to run the file through your hex editor first to convert these to CRLF. If you don't need to convert this file very often, then using your hex editor in this manner is fine. However, if you have to do this often, then you might want to use an automated method, in which case, I can send you a utility program of mine by email. For this, send me your email address to:
edwardmoneo@gmail.com
Regarding the hex 00 or null, this is one of the "features" of C-type programs. You need to check the data with the hex editor to determine if you need to replace these with spaces or eliminate them. My guess is that you can eliminate them, because in C these are generally the trailing delimiter for ASCII strings. If the data was in binary, then the nulls would be valid as such.
Regards.
*****
Using your hex editor, you have to make sure that the file doesn't have any of the combinations that contain a formfeed, plus it doesn't have the CRCRLF combination.PURPOSE:
Convert a Unix generated report file to a standard text file
with records terminated by a carriage return and linefeed only.
The Unix report file was found to have records terminated with the following
combinations of characters:
CRCRLF (carriage return, carriage return, and linefeed)
CRLF (carriage return and linefeed)
CRFF (carriage return and formfeed)
CR (carriage return only)
FF (formfeed only)
LF (linefeed only)
Note: Even C programs cannot read above report lines as strings,
because strings for C must end in CRLF or LF only.
Assuming the file only has records terminated by a LF, like you said, you still will need to run the file through your hex editor first to convert these to CRLF. If you don't need to convert this file very often, then using your hex editor in this manner is fine. However, if you have to do this often, then you might want to use an automated method, in which case, I can send you a utility program of mine by email. For this, send me your email address to:
edwardmoneo@gmail.com
Regarding the hex 00 or null, this is one of the "features" of C-type programs. You need to check the data with the hex editor to determine if you need to replace these with spaces or eliminate them. My guess is that you can eliminate them, because in C these are generally the trailing delimiter for ASCII strings. If the data was in binary, then the nulls would be valid as such.
Regards.
*****
Just wanted to say "Thanks" to all who helped with the QBX program I wrote. It works fine for now, and I'll probably add a few tweaks here and there to provide a few statistics and such, but I would never have gotten this far had it not been for you folks. Thanks so much!
Moneo, I am interested in the utility you wrote for processing a non-ascii file, so I'll send along my email address. Thanks!
Moneo, I am interested in the utility you wrote for processing a non-ascii file, so I'll send along my email address. Thanks!
cripster
quizzical quad
quizzical quad