[Coco] Programming help needed

[Arthur Flexser]

P.S.  A$="ABCD"+CHR$(0)+"EFGH": PRINT A$ prints "ABCDEFGH", not just
"ABCD".  Also, LEN(A$) gives the string length as 9.

Art


On Sun, Dec 2, 2018 at 12:03 PM Arthur Flexser <flexser at fiu.edu> wrote:

> I think you may be mistaken about a string terminating with a zero.  The
> string's length is conveyed by its descriptor byte in the variable table,
> so there'd be no need for a special termination character.
>
> Art
>
> On Sun, Dec 2, 2018 at 6:24 AM tim franklinlabs.com <tim at franklinlabs.com>
> wrote:
>
>>    A string terminates with a zero. If there's a chr$(0) somewhere in the
>>    midpoint of the string, BASIC would see that as an "End of String" and
>>    stop processing. Only part of the string data would be saved. I haven't
>>    verified this but that's what I would expect.
>>
>>      On December 2, 2018 at 1:19 AM William Astle <[1]lost at l-w.ca> wrote:
>>      On 2018-12-01 5:59 p.m., Paul Shoemaker wrote:
>>
>>      Need some advice. I am trying to store to a disk file a 48x40
>>      section from a PMODE 4 screen.
>>      The method I am attempting to use is to peek the byte values using a
>>      nested loop and save them as a string. For example, A$ = A$ + CHR$
>>      (PEEK(&HE00+X+(Y*32))). Note I am storing the byte value as a CHR$
>>      because doing so makes the completed string length only 240 bytes
>>      long. Creating the string is working fine; I have validated that.
>>      Saving the string to a disk file is not working, however. When I
>>      execute a WRITE #1,A$ followed by a PUT #1,<record #>, Disk BASIC is
>>      not saving entire contents of A$. I believe it is parsing the string
>>      as it goes or something, as it seems to be ignoring or even stopping
>>      on some "special" CHR$ codes.. like CHR$(0).
>>      Is there a way around this?
>>      Thanks!
>>      -Paul
>>
>>      WRITE should be exactly equivalent to PRINT except that it will
>>      surround
>>      string data with quotes (and numeric data won't have quotes). I
>>      assume
>>      you're using READ or INPUT after a "GET" as a way to get the result
>>      back. That *will* stop reading at a NUL byte since NULs terminate
>>      parsing strings in the interpreter.
>>      Basically, your problem is that you are using random files wrong.
>>      What
>>      you're doing is okay for text formatted records. However, it's not
>>      binary safe. What you should be doing is:
>>     1. Open the file with in random/direct mode with a specified record
>>        length.
>>
>>     2. Use FIELD to set up variables for the record:
>>
>>      FIELD #1,<record size> AS F$
>>     3. Put your data into F$ using LSET (or RSET if you want it right
>>
>>      justified). DO NOT simply assign to F$. In fact, don't assign to F$
>>      at
>>      all since it will disassociate it from the file record. For example:
>>      LSET F$ = A$
>>     4. Now use "PUT #1, <record #>"
>>
>>      Reading works the same but use "GET #1, <record number>" and then
>>      access
>>      the string variable specified in the FIELD command. Again, don't
>>      assign
>>      to that variable since that will break its association with the file
>>      record.
>>      The above *is* binary safe.
>>      Obviously, it can be more complicated than that by having multiple
>>      fields for a particular file. You can even have multiple record
>>      structures using different variable names for the same file.
>>      --
>>      Coco mailing list
>>      [2]Coco at maltedmedia.com
>>      [3]https://pairlist5.pair.net/mailman/listinfo/coco
>>
>> References
>>
>>    1. mailto:lost at l-w.ca
>>    2. mailto:Coco at maltedmedia.com
>>    3. https://pairlist5.pair.net/mailman/listinfo/coco
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>>
>