By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD Bug in @LEN Function?

I'm using the @LEN function to get the length of a string. However, when that string contains special escaped characters, such as ^s, the length is wrong. Both the caret and the s are counted as separate characters. The same thing happens with strings enclosed by back-quotes. The back-quote characters are counted.

TCC(30.00.22): C:\>echo %@len[1234]

TCC(30.00.22): C:\>echo %@len[^s1234^s]

TCC(30.00.22): C:\>echo %@len[`12%34`]

TCC(30.00.22): C:\>echo `12%34`
Can you suggest a way around this?

If it were being used in a script, I could do the following:

TCC(30.00.22): C:\>set junk=`12 34` & echo %@len[%junk]
TCC(30.00.22): C:\>set junk=^s12 34^s & echo %@len[%junk]

However, I'm using %@len in a user-defined function so that a generated string will have the right length. That's how I noticed the problem. When I put leading spaces on a string using ^s, the resulting string came out too short.
A few functions (like @CLIPW / @CLIPWN will unescape a string before writing it (because they're not returning a resulting string for something else to process).

But your unknown rogue background processes that are rewriting the clipboard would make this unreliable ...

A few other functions like @REPLACE, @REREPLACE also unescape the strings. And then there's always @EXECSTR, though it's klunky & slow.
I couldn't figure out how to use the CLIP or REPLACE functions. My workaround was to implement what I suggested would work in a batch script. I added

@exec[@set var3$=%3$]

Then, everywhere that I had %@len[%3$], I used %@len[%var3$]. That worked.

Fortunately, speed is not an issue these days for something like this.
[FOX] Ultimate Translator