When does PB automatically conver chr$(0) to a space

[John Petty]

I just did a quick program (8.03) to generate a UDT of the record layout of DBF files. The file output could be read perfectly in either the PB IDE or Notepad with the correct space formatting. It turned out that the field defs(y).nme which is defined as STRING * 11 and contains the names of the fields in the DBF record was padded with chr$(0) if less than 11 characters but the PRINT #fo statement appears to convert them automatically to spaces whilst the STRING t prepared identically for display in a textbox did not. Here is the Code

                        FOR x = 33 TO head.lenhd - 1 STEP 32
                            GET fi, x, defs(y)
                            SELECT CASE defs(y).Ftype
                                CASE "C"
                                    s = " 'a string"
                                CASE "N"
                                    s = " 'a number"
                                CASE "D"
                                    s = " 'a date"
                                CASE "L"
                                    s = " 'true or false"
                                CASE "M"
                                    s = " 'a memo address"
                            END SELECT
                            '**********************************************************************************************
                            'this line is needed for proper display in a textbox %Trept but not the printed string
                            REPLACE CHR$(0) WITH " " IN defs(y).nme
                            '**********************************************************************************************
                            IF DoInc THEN PRINT #fo, SPACE$(4) & defs(y).nme & " as STRING * " & FORMAT$(defs(y).FldLen) & s
                            t = t & SPACE$(4) & defs(y).nme & " as STRING * " & FORMAT$(defs(y).FldLen) & s & $CRLF
                            INCR y
                        NEXT
                        IF DoInc THEN PRINT #fo, "End Type"
                        t = t & "End Type" & $CRLF
                        CONTROL SET TEXT CBHNDL, %Trept, t

and here is the file output without the REPLACE

TYPE UE_Fields
    INDEX       AS STRING * 6 'a number
    RACEDATE    AS STRING * 8 'a date
    TRK         AS STRING * 3 'a string
    TRACKNAME   AS STRING * 20 'a string
    RN          AS STRING * 2 'a string
    TYP         AS STRING * 3 'a string
    DESC        AS STRING * 30 'a string
    CONDITIONS  AS STRING * 20 'a string
    DIST        AS STRING * 4 'a number
    PRIZE       AS STRING * 10 'a number
    NR          AS STRING * 2 'a number
    TC          AS STRING * 1 'a string
    RACETIME    AS STRING * 6 'a number
    TRACKAVG    AS STRING * 6 'a number
    SOT         AS STRING * 5 'a number
    CRAT        AS STRING * 4 'a number
    WRAT        AS STRING * 4 'a number
    SRAT        AS STRING * 4 'a number
END TYPE

Even if I just print the entire string i.e PRINT #fo, t all the chr$(0)'s appear to be replaced with spaces and it looks exactly as above

[Steve Rossell]

When a fixed length string is initialized it is filled with chr$(0)'s and when you assign a value to this fixed length string, if necessary the string is padded with chr$(32)'s.

[Michael Mattias]

>GET fi, x, defs(y)

Simple assignment of a dynamic string (or string literal) to a fixed string datatype is implemented as "LSET (or TYPE SET) USING $SPC"

GET from a file does not work that way... GET just moves the specified number of bytes from the disk to the target regardless of content.

When you put any string variable into a control, the display will be terminated on the first $NUL. I believe PRINT# and WRITE# will also terminate on the first $NUL. MSGBOX will, too.

Lastly, whatever software you are using to inspect a file (eg notepad, Ultra Edit, whatever) may or may not terminate on the first null. (Notepad WILL truncate).

Just as a personal rule, I never assume anything and when I will need to display or print I will replace nuls with space.

MCM

[John Petty]

When a fixed length string is initialized it is filled with chr$(0)'s and when you assign a value to this fixed length string, if necessary the string is padded with chr$(32)'s.

Steve
I knew that, and I also knew Michaels point about what is read from the disk. Please read the code, I never reassign the fixed length string so it is never padded with chr$(32)'s which is why the variable length string t cannot display like the printout in a textbox as it will stop at the first chr$(0), expected situation. I actually during testing had code to detect the chr$(0)s to confirm my suspicion of that being the problem.
Please note my final comment that if I just then PRINT to a file the variable length string t (which by its inability to be completely displayed in the multiline textbox demonstrates the presence of chr$(0)s) it gives an identical output to the single line print I showed. So at some stage a conversion must be being done.
That is why I also checked it in notepad as that should show a non printable ANSII character as a black square (no Michael Windows does not use ASCII by default)