At 2:02 AM -0500 11/19/03, Peter Gatti wrote:
I doubt that I'm doing anything wrong because the other strings save
without a problem. So is this a bug or just an RB limitation?
Joe responded:
There certainly isn't any such RB limitation. Perhaps it's a
limitation of the file format you're using. Without any more details,
I really can't guess.
Since code speaks loader than words, here's the code for writing the
file. Naturally the code for reading the file is formatted the same:
S=f.CreateBinaryFile("type")
S.WriteLong DVDList.ListCount //save listcount for faster for/next
file reads
for x=0 to DVDList.ListCount-1
S.WriteBoolean DVDList.cellcheck(x,0)
S.WriteBoolean DVDList.cellcheck(x,1)
S.WritePString DVDList.cell(x,2)
S.WritePString DVDList.cell(x,3)
S.WritePString DVDList.cell(x,4)
S.WritePString DVDList.cell(x,5)
S.WritePString DVDList.cell(x,6)
S.WritePString DVDList.cell(x,7)
S.WritePString DVDList.cell(x,8)
y=Len(DVDList.cell(x,9))
S.WriteLong y
S.Write DVDList.cell(x,9) // details
S.WritePString DVDList.cell(x,10)
S.WritePString DVDList.cell(x,11)
next
S.close
Notice for the details cell I had to use S.Write instead of
S.WritePString because that cell almost always exceeds the PString 256
byte limit. So I save the length of the string first and then use it to
S.Read(y) in later. I don't know of any other way around this since I
don't know the exact number of characters in any one details cell.
I did some testing. When I use S.WritePString to save the details cell,
option key characters in the text do not corrupt the file. However,
S.WritePString does prefix the option character with another option
character. For example, if the text has a © (option g) in it,
S.WritePString prefixes it with a ¬ character (option l). It ends up
looking like this © when read back into the list. And as I mentioned
S.WritePString is no good because it ignores text after 256 characters.
Now when I use the code above, it will write the row containing the
option character ok, but all the rows following it will be corrupted. I
suppose this may be due to the extra ¬ character added to the length of
the string, it throws the rest of the file out of sync. I don't know.
Christopher Morrill also had this problem, so if you say this should not
happen, then there must be something we are doing wrong. Any help you or
anyone can offer will be greatly appreciated.
Pete Gatti
- - -
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|