|
 - Forum
 - iziBasic
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 257
 Sujet n° 1458 |
Megastring or me? |
le 29/09/2006 @ 03:09
par JoeV
|
Could there be a problem with the megastring input$$ statement or is it me again?
I am trying to read a text file with izibasic on the palm (OS v5.4) but the file was not created using izibasic. Let me explain further.
What I have is a text data file on my pc that I opened on my pc with pspad. The file is close to 100k long and consists of strings that are 25 to 35 bytes in length, ending with a LF character as a delimiter. All bytes are standard ascii printable text chars (except for the LF of course). I then compile this file using makedoc to create a .pdb file as per aldwebs instructions in the izibasic maual. The textdata.pdb file is then hotsynced to the palm. No problem. This is the same method I use to create my izibasic programs. Again, no problem.
The problem comes when I try to read the file. The only way I can think of to do that is to read large chunks of data using the megastring input$$ statement and then scan using getchar$$ for the delimiters. This works fine until I get to the very end of the megastring where the last data string is always corrupted because there are several random bytes tuck in immediately before, and including, the last char. My program always issues a clear$$ prior to the input$$ so the string should be initially nulled out. These seemingly random chars are not in my data file because I have checked it with a hex-editor. Nothing in the file but the pdb header and my ascii strings.
If I issue “input$$ #1,4096”, the manual say that 4096 bytes should be input unless a chr$(0) is encountered. There are no chr$(0)'s in the data portion of my data file. So that statement should always read 4096 bytes (until the last record, of course,) but len$$ always returns a value <4000. Len$$ is correct because I can read the individual megastring characters to see the random bytes and, indeed, there is a chr$(0) at megastring location len$$+1. Where do the chr$(0) and random bytes come from?
I would include my code in this post but it may be unreadable due to all the print statements I've added trying to debug this problem. I've done a search of the forum and cannot find a similar question posted. Am I missing something? Does megastring have a quirk? Is there another way to read my data file?
Thanks
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 1
--------
le 29/09/2006 @ 22:40
par aldweb
visiteur
|
Hello JoeV,
It's neither MegaString, nor You 
Your issue has to do with the DOC format and also the way MakeDoc builds the DOC file.
But you are right to use the MegaString for this kind of purpose.
The DOC format is a set of up to 4KB chunks of data, that are not CHR$(0) ended, when iziBasic works natively with chunks of data terminated with a CHR$(0) character.
Furthermore, in the DOC format, when a chunk maximum size is reached, the next character is to be found in the next chunk. Then, one of your strings will almost always be split between the end of a chunk and the beginning of the following chunk.
Add to this that MakeDoc does not write full 4KB chunks like other DOC tools (except the last chunk which is usually smaller than 4KB), but the size of each chunk is usually among 3KB to 4KB with MakeDoc.
Note: you may use Bird (or RsrcEdit) to see all of the above directly on your device, it is easier than to use an hex editor in the PC.
Knowing this you will understand what happens:
The INPUT$$ reads a 4KB chunk of data in the Palm memory. Then, it checks for a CHR$(0) and adjusts the following characters to CHR$(0) accordingly. And LEN$$ will then return the correct size. If no CHR$(0) character is found, the MegaString is believed to be 4KB big and... this is why the beginning of your MegaString is fed with what you expect to find and the last part of the chunk is filled with unexpected characters, these were the one stored in the Palm memory just after the ones you wanted to retrieve.
At this stage, what I suggest is the following (this is the easy way):
1. use TL-PDB to build your DOC file. This DOC editor will make sure that all but the last chunk of data are 4KB (4096 bytes) big
2. check with Bird what's the size of the last chunk
3. use the MegaString to read the chunks, one after the other (all but the last will be of 4096 bytes big, the last one you know from 2.), be careful with the change of chunk to correctly get the string split in between the 2 chunks
That should make it.
Another way of doing the job would be to build a PDB file, with many small records CHR$(0) terminated instead of a DOC file with LF separators among records. You would have more records but it would be easier to read and parse your file.
If you still have issues, don't hesitate to send me your code and the DOC file (I guarantee 100% confidentiality, all files will be deleted from my PC once the job will be done), I would give you a hand to finish this little coding with a DOC file.
Cheers,
@+
aldweb |
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 2
--------
le 01/10/2006 @ 00:45
par JoeV
visiteur
|
Thanks so much for your help, aldweb!
Before reading your post, I dissected my pdb data file created by makedoc. Looking at the file header, I noticed that the record lengths were indeed less than 4K. For my file, they varied between 3968 to 4080 bytes. I have since downloaded TLPDB, as you recommended, and that fixed the problem.
TLPDB does create record lengths of 4096 bytes. This I verified, again, by looking at the file header. The len$$ statement, however, returns a length of 4095. It will return 4095 whether I issue an “input$$ #1” or an “input$$ #1, 4096” statement. The first statement will put a chr$(0) in megastring position 4096 but the second statement will fill that location with valid data. Therefore, to properly read my data file, I must (1) use input$$ #1,4096 and (2) increment len$$. Perhaps I do not understand len$$ and input$$ correctly.
BTW, I am enjoying izibasic immensely. I had forgotten how much fun programming in basic could be. My current project involves coordinate transformation, matrix manipulation, and is trigonometrically intensive. I am amazed how fast the compiled code does the calculations. I have one hurdle left to jump and that involves two way communications with either the irda or usb ports. For that, I understand, I must learn pascal.
Thank you again.
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 3
--------
le 02/10/2006 @ 00:05
par aldweb
visiteur
|
The len$$ statement, however, returns a length of 4095. It will return 4095 whether I issue an “input$$ #1” or an “input$$ #1, 4096” statement. The first statement will put a chr$(0) in megastring position 4096 but the second statement will fill that location with valid data. Therefore, to properly read my data file, I must (1) use input$$ #1,4096 and (2) increment len$$. Perhaps I do not understand len$$ and input$$ correctly.
There might also be a bug at the 4096 limit. I will check that.
BTW, I am enjoying izibasic immensely.
Thank you for writing this, it's always a pleasure to read such comments. 
I have one hurdle left to jump and that involves two way communications with either the irda or usb ports. For that, I understand, I must learn pascal.
Indeed... And I would be interested to get some Pascal (PP) source code for managing IRDA and USB ports. This would dramatically help me improving iziBasic in this area.
Cheers,
@+
aldweb |
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 4
--------
le 02/10/2006 @ 14:40
par JoeV
visiteur
|
Aldweb,
"Indeed... And I would be interested to get some Pascal (PP) source code for managing IRDA and USB ports. This would dramatically help me improving iziBasic in this area."
You are welcome to my code if/when I get it working. But I have some research and studying to do before I begin. I will post if I get stuck. Thanks again.
JoeV |
|
|
|
sujet actif
 sujet clos
 Important!
 Nouveau message -
 Rectifier message
 Clôturer sujet
 Remonter
|
|
I. aldweb
![[de]](img/de.gif)
![[es]](img/es.gif)
![[it]](img/it.gif)
![[pt]](img/pt.gif)
visiteurs
Haut 
© 2004-2013 
