New _TRIM$ function

[FellippeHeitor]

Oh hey! there is a _Trim$ keyword! I never thought to check a _version.

It's only in development builds so far; it'll become official in the next release of QB64 as outlined here: https://www.qb64.org/forum/index.php?topic=304.msg2554#msg2554

[bplus]

Oh hey! there is a _Trim$ keyword! I never thought to check a _version.

It's only in development builds so far; it'll become official in the next release of QB64 as outlined here: https://www.qb64.org/forum/index.php?topic=304.msg2554#msg2554

I don't think it likes to play with +

Code: QB64: [Select]

1. PRINT _TRIM$("                   hello world      ")
2. PRINT "*" + _TRIM$("                   hello world      ") + "*"
3. PRINT "*"; _TRIM$("                   hello world      "); "*"
4.  

For my system the middle line is blank.

[FellippeHeitor]

That's the type of pushing the limits we need when we announce we're beta testing a new version. Thanks. I'll look into the issue.

PS: Although it does work for me as expected, both on Windows (32bit) and macOS (64bit):

  [ You are not allowed to view this attachment ]  

  [ You are not allowed to view this attachment ]  

Anything we should know about your setup?

[SMcNeill]

That's the type of pushing the limits we need when we announce we're beta testing a new version. Thanks. I'll look into the issue.

PS: Although it does work for me as expected, both on Windows (32bit) and macOS (64bit):

Anything we should know about your setup?

Windows 64bit performs as bplus indicates above, for me, along with a secondary issue:

Code: QB64: [Select]

1. a$ = "*" + _TRIM$("                   hello world      ") + "*"
2.  
3. PRINT a$

The above compiles, runs, and instantly self-destructs and closes before GL can even render a screen for us.  A program of "SYSTEM" would have a more noticeable effect than the above does, on my machine.  NO GL window opens.  There's no error messages -- not even a "C++ failed blah blah blah" message.  No "Press Any key to continue" message...   

[FellippeHeitor]

Can both of you please confirm you're running the latest development build tagged 6fde149?

[bplus]

Hi Fellippe,

Here is what I am running:
'QB64 X 64 version 1.2 20180228/86  from git b301f92

maybe fixed now?

 

[FellippeHeitor]

That's at least 11 builds behind. Please try the latest.

For reference: https://github.com/flukiluke/qb64/commits/development (where build numbers come from).

[bplus]

OK extracting now, is this 64 x 64?

append:
  [ You are not allowed to view this attachment ]  

No not 64 x 64.  ;(

[SMcNeill]

OK extracting now, is this 64 x 64?

Only 32-bit.  You have to build the x64 version yourself.

[bplus]

OK extracting now, is this 64 x 64?

Only 32-bit.  You have to build the x64 version yourself.

Oh boy! I think I got the 64 x64 version from you Steve. ;)

[FellippeHeitor]

It'll make sense for you 64bitcrazy guys to convert the last stable version to 64bit and wait for the current dev build to become stable before you convert it again, especially considering it can be buggy and it is constantly being updated until stable is reached.

[codeguy]

Pretty much the simplest and fastest for extracting substrings cleared of leading and trailing spaces. I would modify this for eliminating anything below ascii 33.

[FellippeHeitor]

Agree to disagree, codeguy. Fastest is RTRIM$(LTRIM$(text$)), which is what _TRIM$ does internally.

[codeguy]

Indeed much faster. Does yours offer flexibility to do more than just eliminating padding characters <= ascii 32?

[FellippeHeitor]

Nope, it does just what it promises: work as a macro to RTRIM$(LTRIM$(text$)). It's available in the latest dev build you can get from the homepage and will come in the next version of QB64 as soon as it's made available. It'll likely be called 1.3.