TYPE vars white spaces

[xra7en]

so working along on records...

using TYPE records, the following example

text as string * 300

while waiting for user input, I display the current (which is blank at the start),

so what it looks like at run time:

option 1: this option
option 2: this option
option 3: text




option 4: more options
option 5: more text..

notice the white space for option 3 (in this example)

when I use _TRIM$(text) it does not do what I would expect.

what kind of characters make up that space (NOTE: once I edit that line, all the white-space goes apply)
is there a way to display it while it is blank?

[FellippeHeitor]

Try using LEFT$(text, INSTR(text, CHR$(0)) - 1).

[Pete]

To explain further, those "white-spaces" are null characters represented as CHR$(0). They are added to strings less than their dimension limits, so text = "abc" would be recorded as abc with 277 CHR$(0) characters following the "c" in your DIM text as STRING * 300 example.

Fell's line of code will strip the null characters off your text variable.

Pete

[xra7en]

o duh, forgot about nul. I knew it was something along those lines. :-)

thanks guys

[RhoSigma]

To explain further, those "white-spaces" are null characters represented as CHR$(0). They are added to strings less than their dimension limits, so text = "abc" would be recorded as abc with 277 CHR$(0) characters following the "c" in your DIM text as STRING * 300 example.

Fell's line of code will strip the null characters off your text variable.

Pete

Just half of the truth, usually a regular assignment such as text = "abc" does fill the remaining 277 (or whatever) bytes with spaces on fixed length strings, but if you're just replacing chars in the form MID$(text, 1, 3) = "abc", then the other bytes remain uninitialized, hence CHR$(0).

That's why I usually do a xxx = "" on any fixed length strings first anywhere in my program's init procedure, it will make it all spaces and then you can also use MID$ for char replacement without leaving the other parts uninitialized, as they are already spaces after the first assignment.

BTW - xra7en, that's also the reason that it works, once you have edited/assigned it once.

[xra7en]

most of that I figured. the chr$(0) slipped my mind that is WAS NOT a character, and because of that, I thought the _TRIM$() would take care of it.
also, was taking the easy rout. instead of making a whole new varible(s). I just used the existing type record to input example

Code: QB64: [Select]

1. type tRoom
2. pname as string * 40
3. desc as string *300
4. end type
5.  
6. dim room as troom
7.  
8. 'show current stuff
9. print "name = ";room.pname
10. print "desc = ";room.desc '<--- oops lots of spaces the first time (lazy or efficient?)
11.  
12.  
13. input room.pname
14. input room.desc
15.  

after user adds the data, all looks good.
 it is more aesthetics than anything.

However, recently, I just decided to add the dummy vars to use and then when done, made the record vars equal the dummy vars.

[Aurel]

I am not expert for qb64 but i know something about basic.
First as far as i know white-space or blank char -> " "... is chr(32) not chr(0)
chr(0) is empty string char -> ""

[Pete]

CHR$(0) can show up in strings through odd events. Here is an example...

Code: QB64: [Select]

1. DIM x AS STRING * 20
2. DIM a AS STRING * 10
3. OPEN "tmp.tmp" FOR OUTPUT AS #1: CLOSE #1
4. OPEN "tmp.tmp" FOR RANDOM AS #1 LEN = 20
5. a = "123"
6. PUT #1, 1, a$
7. GET #1, 1, x
8. CLOSE #1
9.  
10. FOR i = 1 TO 20
11.     PRINT ASC(MID$(x, i, 1)), MID$(x, i, 1), x
12. NEXT
13. PRINT STRING$(10, CHR$(0)); "|"
14.  

Now if you coded a AS STRING * 20, it would show all chr$(32) spaces. You can really screw with the output if you get rid of the DIM a and change a = "123" to a$ = "123". QB64 must love it, because it returns a leading heart. CHR$(3)

CHR$(0) does take up space, btw. It's just an invisible character, like CHR$(32) and CHR$(255).

PRINT STRING$(10, CHR$(0));"|"

Pete

[FellippeHeitor]

CHR$(3) showing up when you use a variable length string instead of a fixed length one is merely a "header" indicating the size of the string. Making a$ = "four" or whatever other four-character string will yield a diamond, as that's chr$(4).

[Pete]

And what happens if my string is 200,000 characters long? Does the "heart" explode?

Pete

[FellippeHeitor]

From internal/c/libqb.cpp:

//put2 adds a 2-4 byte length descriptor to the data
//(used to PUT variable length strings in RANDOM mode)
void sub_put2(int32 i,int64 offset,void *element,int32 passed){

If the length of the string is less than 32767, it's stored using an INTEGER (2 bytes). If greater than that, it's stored using a LONG (4 bytes).

[Pete]

Interesting.

When I first started using RA files, I did not take the time to study TYPE or fixed length strings. I don't think I even knew what a fixed length string was. So I did get that RA files had to have a way to access records, and if the string was not the correct length, it would cause a bad record error. I found a way around all of this by adding +2 to the LEN statement that was set to the length of the longest string I wanted stored...

Code: QB64: [Select]

1. REDIM a$(10), b$(10)
2. OPEN "tmp.tmp" FOR OUTPUT AS #1: CLOSE #1
3. a$(1) = "This is an example"
4. a$(2) = "of using a random access format"
5. a$(3) = "that can handle strings of"
6. a$(4) = "varying lengths."
7. FOR i = 1 TO 4
8.     IF LEN(a$(i)) > max THEN max = LEN(a$(i))
9. NEXT
10. WIDTH 80, 42
11. _SCREENMOVE 0, 0
12. OPEN "tmp.tmp" FOR RANDOM AS #1 LEN = max + 2
13. FOR i = 1 TO 4
14.     PUT #1, i, a$(i)
15. NEXT
16. FOR i = 1 TO 4
17.     GET #1, i, b$(i)
18. NEXT
19. CLOSE #1
20.  
21. FOR h = 1 TO 4
22.     PRINT b$(h)
23. NEXT
24. SLEEP
25. FOR h = 1 TO 4
26.     CLS
27.     FOR i = 1 TO LEN(b$(h))
28.         PRINT ASC(MID$(b$(h), i, 1)), MID$(b$(h), i, 1)
29.     NEXT
30.     SLEEP
31. NEXT
32.  

Pete

[SMcNeill]

When I first started using RA files, I did not take the time to study TYPE or fixed length strings. I don't think I even knew what a fixed length string was. So I did get that RA files had to have a way to access records, and if the string was not the correct length, it would cause a bad record error. I found a way around all of this by adding +2 to the LEN statement that was set to the length of the longest string I wanted stored...

If the length of the strings may end up being longer than 32766 characters, yuo'd want to make that statement + 4.  ;)

[Pete]

My strings seldom exceed those levels... unless I'm cursing out Democrats.

Pete ;)

[xra7en]

Interesting.

When I first started using RA files, I did not take the time to study TYPE or fixed length strings. I don't think I even knew what a fixed length string was. So I did get that RA files had to have a way to access records, and if the string was not the correct length, it would cause a bad record error. I found a way around all of this by adding +2 to the LEN statement that was set to the length of the longest string I wanted stored...

OK, I'm old school, what is RA files? to me that reads Remote Access (bbs days) files.