Line Input Limitation?

If you have questions about any aspect of QBasic programming, or would like to help fellow programmers solve their problems, check out this board!

Moderators: Pete, Mods

Post Reply
cripster
Newbie
Posts: 4
Joined: Sat Jul 15, 2006 3:38 pm

Line Input Limitation?

Post by cripster »

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!
cripster
quizzical quad
RayBritton
Veteran
Posts: 109
Joined: Thu Feb 10, 2005 12:38 pm

Post by RayBritton »

can you post your code please
cripster
Newbie
Posts: 4
Joined: Sat Jul 15, 2006 3:38 pm

Post by cripster »

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
Yeah, it's real rudimentary, but it works as long as upt3a.log is < 32767 bytes, and returns and ILLEGAL FUNCTION CALL if it is larger.
cripster
quizzical quad
moneo
Veteran
Posts: 451
Joined: Tue Jun 28, 2005 7:00 pm
Location: Mexico City, Mexico

Re: Line Input Limitation?

Post by moneo »

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.

*****
cripster
Newbie
Posts: 4
Joined: Sat Jul 15, 2006 3:38 pm

Re: Line Input Limitation?

Post by cripster »

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......
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.
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)

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:
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.

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...
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.
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!
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.
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.

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.
Wouldn't have a clue about how to read the UNIX type file in chunks! :)

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
moneo
Veteran
Posts: 451
Joined: Tue Jun 28, 2005 7:00 pm
Location: Mexico City, Mexico

Post by moneo »

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:
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.
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.

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.
*****
cripster
Newbie
Posts: 4
Joined: Sat Jul 15, 2006 3:38 pm

Post by cripster »

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! :D

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
Post Reply