Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: xra7en on January 13, 2019, 05:48:49 pm

Title: TYPE vars white spaces
Post by: xra7en on January 13, 2019, 05:48:49 pm
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?


Title: Re: TYPE vars white spaces
Post by: FellippeHeitor on January 13, 2019, 07:19:06 pm
Try using LEFT$(text, INSTR(text, CHR$(0)) - 1).
Title: Re: TYPE vars white spaces
Post by: Pete on January 13, 2019, 07:33:44 pm
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
Title: Re: TYPE vars white spaces
Post by: xra7en on January 13, 2019, 07:57:25 pm
o duh, forgot about nul. I knew it was something along those lines. :-)

thanks guys
Title: Re: TYPE vars white spaces
Post by: RhoSigma on January 14, 2019, 01:32:14 am
Quote from: Pete on January 13, 2019, 07:33:44 pm
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.

Title: Re: TYPE vars white spaces
Post by: xra7en on January 14, 2019, 04:29:47 pm
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
  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.
Title: Re: TYPE vars white spaces
Post by: Aurel on January 15, 2019, 11:22:40 am
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 -> ""
Title: Re: TYPE vars white spaces
Post by: Pete on January 15, 2019, 01:26:03 pm
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
  9.  
  10. FOR i = 1 TO 20
  11.     PRINT ASC(MID$(x, i, 1)), MID$(x, i, 1), x
  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
Title: Re: TYPE vars white spaces
Post by: FellippeHeitor on January 15, 2019, 01:46:47 pm
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).
Title: Re: TYPE vars white spaces
Post by: Pete on January 15, 2019, 02:44:22 pm
And what happens if my string is 200,000 characters long? Does the "heart" explode?

Pete
Title: Re: TYPE vars white spaces
Post by: FellippeHeitor on January 15, 2019, 03:26:04 pm
From internal/c/libqb.cpp:
Quote
//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).
Title: Re: TYPE vars white spaces
Post by: Pete on January 15, 2019, 04:07:52 pm
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))
  10. WIDTH 80, 42
  12. OPEN "tmp.tmp" FOR RANDOM AS #1 LEN = max + 2
  13. FOR i = 1 TO 4
  14.     PUT #1, i, a$(i)
  16. FOR i = 1 TO 4
  17.     GET #1, i, b$(i)
  20.  
  21. FOR h = 1 TO 4
  22.     PRINT b$(h)
  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
  32.  

Pete
Title: Re: TYPE vars white spaces
Post by: SMcNeill on January 15, 2019, 04:22:30 pm
Quote from: Pete on January 15, 2019, 04:07:52 pm
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.  ;)

Title: Re: TYPE vars white spaces
Post by: Pete on January 15, 2019, 06:42:51 pm
My strings seldom exceed those levels... unless I'm cursing out Democrats.

Pete ;)

Title: Re: TYPE vars white spaces
Post by: xra7en on January 17, 2019, 10:06:47 pm
Quote from: Pete on January 15, 2019, 04:07:52 pm
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.
Title: Re: TYPE vars white spaces
Post by: SMcNeill on January 17, 2019, 10:18:50 pm
Random Access.


OPEN file$ FOR RANDOM AS #1
Title: Re: TYPE vars white spaces
Post by: xra7en on January 18, 2019, 10:51:10 am
Well gee, I ALMOST feel like a dork - I think logically: QB is old school, (BBS days, along with pascal and C#) So when I hear RA .....

now I gotta change ma lingo again...  :-)
Title: Re: TYPE vars white spaces
Post by: Pete on January 18, 2019, 11:16:31 am
Don't feel bad, you just didn't get the memo. You could take it up with our HR department, unless you don't know what HR stands for, in which case you're screwed, unless you don't know what screwed stands for, in which case you just might be a dork.

Kidding aside, this is a neat community in that you don't see a lot of arrogance flying around about how you posted something. Around here, it's more about reaching some level of understanding to make some headway or to be able to adequately discuss a topic. I've been to some of those other forums and told them I'd like to stay and chat, but I'm too busy taking all the online PhD courses, so I can correctly relate something without having to climb down someone's throat because they picked apart my post, even though they did understand what I was trying to ask.

Oh, here's a fun fact. Did you know nul is the abbreviation of null? Who in the "hel" thought we needed a shorter way to write a 4-letter word?

BTW - I really like that saying in your signature line... "Light is faster than sound, that is why people APPEAR intelligent until they speak."

Pete :D

Text Only | Text with Attachments