[v1.8.3.6] "{CMDWHENISAY}" is lowercase when executing by name

[Pfeil]

When the "Execute by name (Advanced)" option of the "Execute Another Command" action is used, the "{CMDWHENISAY}" token will return the contents of the "When I say:" field of the executed command all lowercase (regardless of how it was capitalized in the "Execute by name (Advanced)" textbox).

E.G. when executing "New Command 3" using speech, the "Execute selected command" option of the "Execute Another Command" action, or the "Execute" option in the context menu of the command list,

Code: [Select]

Write [Blue] '{CMDWHENISAY}' to logwill write

Code: [Select]

New Command 3to the log.

But, when using the "Execute by name (Advanced)" option of the "Execute Another Command" action,

Code: [Select]

new command 3is written instead.


Normally this won't cause issues in VoiceAttack itself as it compares strings in a case-insensitive manner, but plugins may not (which is how I came across this).


This goes back to v1.6.2 when "{CMDWHENISAY}" was added.


EDIT: Changed to work as expected (returns the full contents of the "When I say" field, identically capitalized) in v1.8.3.7

[Gary]

Ah - I see.

[Clear as mud alert]  -  I'm able to reproduce this, however, the best that this can be fixed is that the value indicated for, 'Execute by name (Advanced)' must be cased the way you would want it to appear in, '{CMDWHENISAY}'.  So, if your subcommand's, 'when i say' value is, 'New Command 3' and you execute it by passing in, 'NeW CoMmAnD 3', you'll get back, 'NeW CoMmAnD 3' in {CMDWHENISAY}.  The reason is that the value being passed in is being used is because of dynamic/multi commands (so that you can execute a command by name by using just one element of a dynamic/multi command string).  If your subcommand is 'New Command 3;New Command 4', the value established for the subcommand's command string (when i say) when it is executed is not, 'New Command 3;New Command 4', but rather whatever you passed in (which is set to lower and then compared to the dictionary - it's why you get back a lower-cased value).  I don't know why this ended up this way.  It wouldn't be hard to make the subcommand return the full, 'when i say', but I hesitate because that would have taken zero lines of code versus all this legwork.  I also worry that the change that I'm making may break folks out there that depend on this being lower case.

Side note - I *could* go in and make it where it resolves the proper casing, but that would add an overhead penalty across the board for this type of execution.

Kind of a weird situation.  Thanks for all the great info - the change will be in the next update!

[Pfeil]

Unfortunately mismatched case is a minor issue compared to the fact that "{CMDWHENISAY}" doesn't function as described at all when used with "Execute by name (Advanced)", in that it does not actually return the contents of the "When I say" field.

I often use "{CMDWHENISAY}" to provide a unique prefix for variables, in order to make the same command duplicatable without having to manually change variable names to prevent interference between different commands (this applies to variables that cannot be command-scoped), E.G. ">>{CMDWHENISAY}myVariable".

This means that a command that is executed by any means other than the "Execute Another Command" action with the "Execute by name (Advanced)" option, would behave unpredictably when or after being executed using that method, as the variable names would be different and data would not be stored as expected.


This restriction does not appear to be documented, either with the "{CMDWHENISAY}" token, or the "'Execute Another Command'" section.

[Gary]

I can have the subcommand return the command string, just like the base command does- I just don't know why there was work done to make it return what was passed in.  Again - it could cause problems for others (only one way to find out ).