en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en en en en en en en en de en en en en en nl en en en en en en en en en en en en en nl en en en en en en en en en en en fr en da en en en en en en en nl en en en en en en en en en en en en de en en en fr en en en en en en en en en pt en en en en en en
By logging into your account, you agree to our Privacy Policy, personal data processing and storage practices as described therein.
Forgot password or user name?
Search in titles only Search in PowerBASIC for Windows only
You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
When does PB automatically conver chr$(0) to a space
All Time Today Last Week Last Month
All Discussions only Photos only Videos only Links only Polls only Events only
Join Date: Feb 2000
When does PB automatically conver chr$(0) to a space
9 Jul 2009, 10:02 AM
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
Last edited by John Petty; 9 Jul 2009, 10:05 AM.
Join Date: Mar 2005
9 Jul 2009, 10:29 AM
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.
Join Date: Aug 1998
9 Jul 2009, 10:30 AM
>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.
Port Washington WI USA
Join Date: Feb 2000
9 Jul 2009, 11:36 AM
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.
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)
Copyright © 1998-2022 PowerBASIC Tools, LLC - All Rights Reserved.
Powered by vBulletin® Version 5.7.0
Copyright © 2022 vBulletin Solutions, Inc. All rights reserved.
All times are GMT-5. This page was generated at 03:56 AM.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.