Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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
    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
    Code:
    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
    Last edited by John Petty; 9 Jul 2009, 11:05 AM.

  • #2
    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.
    Sincerely,

    Steve Rossell
    PowerBASIC Staff

    Comment


    • #3
      >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
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        Originally posted by Steve Rossell View Post
        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)

        Comment

        Working...
        X