Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / is there a character limit for ReadLine() or have I found a bug?

Author
Message
TomToad
6
Years of Service
User Offline
Joined: 6th Jan 2018
Location:
Posted: 23rd Feb 2018 08:26
Link
I am trying to load a text file into a string. I did not see any kind of LoadText() command, so I created my own

It seems to work ok. Problem is that a text file I am loading has one extremely long line, over 38,000 characters, The line reads in fine. The next line reads in part of the previous line, then the EOF is flagged even though I have about a dozen lines after the long line. Everything loaded in fine when I broke the line down into a bunch of smaller lines.

So 2 questions
Is there a limit on how long a line can be when using ReadLine()
Is there better way to load a text file into a string?
Back to top
Profile PM Email
Zep
21
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 23rd Feb 2018 10:17 Edited at: 23rd Feb 2018 10:22
Link
This is DBPRO, but you should get the idea, (not real code, but almost)

flag=0
open file "test",1
for x = 1 to EOF //read to end of file.
read byte 1,b
if b = 13 then read byte 1,b //ignore carriage return, get next byte
if b = 10 then read byte 1,b:flag=1 //Start a new string if flag=1...ignore line feed, get next byte, if flag = 1 start reading the next string....
string1=string1+str$(b) //you would do something like this. you would also check before if the "flag" = 1 and if so, start a new string, and set "flag" back to 0
next x
close file 1

you will add each byte into a string., when you reach CR/LF of each line, start a new string

Sorry not perfect code logic, but I'm a little busy right now.
Back to top
Profile PM Email
Zep
21
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 23rd Feb 2018 10:29
Link
maybe it would be val(b) instead of str$(b)

I forget exactly right now
Back to top
Profile PM Email
Zep
21
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 23rd Feb 2018 10:34
Link
but a 38,000 length string IS kind of long...

That could be your problem...don't know
Back to top
Profile PM Email
Zep
21
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 23rd Feb 2018 10:40
Link
Also remember "strings" typically have a delimiter, usually "," in a text file

So when reading a string, it will stop reading the "string" when you hit the delimiter. and start reading the same line until EOF or you hit another delimiter.



Back to top
Profile PM Email
Zep
21
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 23rd Feb 2018 10:49
Link
Quote: "Also remember "strings" typically have a delimiter, usually "," in a text file
"


That's why I read bytes and add the bytes to string and check for CF/LF (End of Line)(to bypass any delimiter nonsense), if I have 1 string per line

Back to top
Profile PM Email
Zep
21
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 23rd Feb 2018 10:53
Link
oh, instead of val() or str$(), it might be chr$()
Back to top
Profile PM Email
TomToad
6
Years of Service
User Offline
Joined: 6th Jan 2018
Location:
Posted: 24th Feb 2018 09:26
Link
Reading byte for byte would work, but it also would be slow. Better for me to just load the file in notepad++ and break up the long lines. When you use ReadLine(), it reads until the EOL character (Chr$(10)). Other characters, such as "," are read in as is and are not interpreted as a delimiter. This is verified as when the lines are shortened, all characters, including "," are read correctly.

I haven't had a chance to check exactly how long a line needs to be before problems occur, but I suspect it is around 32768. Most likely, AppGameKit is using a signed short to determine how many bytes are read and calculate how far to advance the file pointer. Since signed shorts max at 32767, reading more than that will make the count roll over to negative, causing the calculations to break down.
Back to top
Profile PM Email
Zep
21
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 24th Feb 2018 09:30
Link
Quote: "I haven't had a chance to check exactly how long a line needs to be before problems occur, but I suspect it is around 32768. Most likely, AppGameKit is using a signed short to determine how many bytes are read and calculate how far to advance the file pointer. Since signed shorts max at 32767, reading more than that will make the count roll over to negative, causing the calculations to break down.
"


That makes sense, but you said it reads the line just fine and fails afterwards.

I'd do some kind of test and do a len(string) and see what number it reports after reading the long line.
Back to top
Profile PM Email
TomToad
6
Years of Service
User Offline
Joined: 6th Jan 2018
Location:
Posted: 24th Feb 2018 09:34
Link
Loading in the file like this works

Back to top
Profile PM Email
Zep
21
Years of Service
User Offline
Joined: 31st Aug 2002
Location: From PA, USA. Currently reside in Hanoi, Vietnam
Posted: 24th Feb 2018 09:47
Link
so do a
length1=len(result)
and see what # you get for length1



Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-04-23 16:11:58
Your offset time is: 2024-04-23 16:11:58