[v1.5.12.16] "{STATE_KEYSTATE:}" token does not work for "SHIFT" and "LSHIFT"

[Pfeil]

Neither "{STATE_KEYSTATE:LSHIFT}" or "{STATE_KEYSTATE:SHIFT}" return "1" when the left shift key is pressed.

I have tested every non-typeable Key State Token Parameter in the help document; These two are the only ones that don't function properly.

[Gary]

Ack!  You are correct.  Will fix now

[Gary]

New beta out there.  Also, I got nested tokens in there just for you

[Pfeil]

"{STATE_KEYSTATE:}" works with "SHIFT" and "LSHIFT" again. Fixed.


On the subject of nested tokens:

This is going to make complex operations so much simpler, awesome feature!

Now that "{}" will be replaced with "", perhaps an escape sequence could be implemented to suppress this behavior?

I had typed up a report on the issue of the contents of "{CLIP}" getting interpreted as tokens, which wasn't a big issue then as it would only match semi-valid tokens within that string. However, with this implementation any text with curly braces may get blanked out.

Because VoiceAttack generally works with tokens(and having "\" as an escape character would cause issues by itself), I suggest something like "{LIT:}", which tells the parser to treat the contents of the token as literal.

As you've explained the way tokens are parsed, I'm hoping it'd be possible to parse every token until only the "{LIT:}" tokens remain, and then parse those as the last step.

This also ties in to the ability to allow some processing to the contents of "{LIT:}", by passing it a parameter for the recursion depth: "{LIT:{CLIP}:1}" would parse "{CLIP}", but not its contents, and because the recursion depth is "1", the token would be converted to "{LIT:Contents of clipboard}", which would then tell the parser to leave that token and its contents alone until the final pass.

[Gary]

I wasn't totally comfortable leaving it like that, so I'll probably go with just returning whatever is in the brackets (sans brackets... which is what was in there initially) and probably allow for \{ and \} to be ignored.

[Pfeil]

probably allow for \{ and \} to be ignored.

Fair enough, as it's possible to use "{TXTREPLACEVAR:::}" to automatically escape text.

Though, this brings up the subject of variable input for tokens; Is it somewhat superseded by nested tokens?

Obviously, tokens solely intended for retrieving a variable still require it, however, things like "{TXTNUM:}", "{WINDOWEXISTS:}", "{TXTCONCAT::}", and especially "{TXTPOS:::}" or "{TXTREPLACEVAR:::}"(which each require 3 variables) would be so much simpler to use if they took input directly.

I realize that it's unfeasible to simply disable variable functionality, as it would break profiles, so perhaps it would be possible to derive the intended use from the presence of singlequotes(in the case of text), or the input consisting solely of numerals(for integers).

[Gary]

I'm in the process of updating the tokens that accept a variable to accept literal values as well.  As I test, I'm keeping the commands to build a token sample profile (might be helpful).  Kind of a slow and tedious process between code and documentation o_O

[Pfeil]

Excellent. That'll complement the nested token functionality very well.

I wonder, will the deprecated become the deprecator, as "TXTREPLACE" could have the new functionality and supplant "TXTREPLACEVAR".

[Gary]

I've done {TXTLEN:variable} already.  Anything other than a variable will need to be in quotes:

{TXTLEN:myTextVar}

or

{TXTLEN:"my literal text"}

or

{TXTLEN:"Hello, {TXT:someOtherVariable}."}


Working through each, as time permits.

[Gary]

New beta is out there.  I updated some of the tokens to accept literals/tokens.  It's mostly {TXT*} tokens, and some of the other types like {INT:}, {DEC:}, etc that now allow for default values.  {TXTREPLACE:} is still deprecated and replaced by {TXTREPLACEVAR:}.  {TXTREPLACEVAR:} now allows for literals / tokens.

[Pfeil]

From the documentation, the following should now accept "literals":

• {TXTLEN:}
• {TXTUPPER:}
• {TXTLOWER:}
• {TXTTRIM:}
• {TXTREPLACEVAR:}
• {TXTNUM:}
• {TXTALPHA:}
• {TXTTITLE:}
• {TXTCONCAT:}
• {TXTPOS:}

All seem to work fine in their basic form, as expected.


There is something else though: If a VoiceAttack is presented with a "stray" "{" character, the command will infinitely loop, running at 100% CPU core usage, and unable to be terminated by anything other than completely shutting down VoiceAttack.

It can be as short as

Code: [Select]

Write '[Blue] {' to log
or part of a token

Code: [Select]

Write '[Blue] {BOOL:te{st}' to log

Worse still, using it when setting a variable

Code: [Select]

Set Text [test] to '{'
Will also hang the UI, so the only way to stop VoiceAttack is to kill the process, leading to an "improper shutdown" warning next startup.

[Gary]

Yikes!  I was missing a break in that last little bit that was done.  I'll have a new beta out soon.
Great catch

[Gary]

I put another beta out there.  Working this toward a full release at the beginning of November.