{LASTCMD}, {CMDCOUNT} tokens

[PsiQss]

Hello Gary. I'm programming some nice little plugin thingy and I'm in terrible need of spying the executed commands from within the plugin :3 No shady business here, I would just want to keep track of last used commands to do some fancy magic with it. After asking around on the forums we've come to conclusion that there are two more things I would need to achieve this:

- {LASTCMD} token, which would let me check if the same command has been used recently, regardless of spoken segment options. It would work the same as {LASTSPOKENCMD}, except that it would contain the whole "when I say" string
- {CMDCOUNT} token - an integer that would keep track of how many commands were executed since the start of VA. (Thanks Pfeil for this suggestion!)

The CMDCOUNT is just one option to get what I really need, which is to detect a command execution. Another idea I've come up with is a boolean token that would return true as long as the command is being executed, I don't know what would be more versatile and useful in general.

I just need a way for the plugin to tell that a new command is being executed, so I can store it in database, with the date it was used, and maybe also some cmd category or whatever. If you're interested in why I need this, I tried to explain it in this wall of text.
Maybe you have a better idea how could this be done?

Would it be possible to implement those two things? Or at least the second token?

[Gary]

A command count token, although would be useful for your situation, would require VA to keep lists of usage counts for every command, based on the trigger type: spoken, hotkey, mouse, etc.  That's kind of a lot of overhead for something this specific.  What I mean by overhead is that there would be a time/resource penalty associated with every command call for *everybody*.

You may want to try creating and increment your own variable within the commands that you care about, and that way the resource penalty is solely where it needs to be:

Set integer [>myVal] to [>myVal] plus 1

(note the > means, 'profile-scoped').


I added, '{CMDWHENISAY}' to give the full value of what is in the, 'when i say' box.  You can also put that in a variable or series of variables to track.  It's in the, 'unofficial' bin if you want to use it before the next beta:  http://www.voiceattack.com/unofficial
 

[PsiQss]

Great, thank you!

As for the {CMDCOUNT} token, I didn't mean a separate count for each command, but one global variable that would increment each time a VA recognized command was executed. My plugin would keep an eye on this value, and each time it incremented it would indicate that some command was just executed, so it could store the value of newly implemented {CMDWHENISAY} in the database. How about the boolean {CMDEXECUTING}? It would be FALSE most of the time, change to TRUE when a command began executing and then switch back to FALSE when a command was done.

All I need is a way for my plugin to detect when a command was executed so that it knows when to read what WAS the command. Without having access to the command itselt (purely from within the plugin, so that I can keep track of all other profiles). I could test {LASTSPOKENCMD} in a loop, and just store the value every time it changed, but that won't work in case of the same being executed in a row.

Oh and one question about the {CMDWHENISAY} token - it does not just store the value of the command that reads it? I can read the value from the plugin, with va_Proxy, right?

[Gary]

You should be able to read that from the plugin with the ParseTokens() function.  It's actually part of the referenced command and is readily available.

[PsiQss]

You may want to try creating and increment your own variable within the commands that you care about, and that way the resource penalty is solely where it needs to be:

Set integer [>myVal] to [>myVal] plus 1

(note the > means, 'profile-scoped').

The idea is for my plugin to detect commands from external profiles, so that users don't have to add an action to every single command. The plugin is supposed to run a loop check in the background, and every time it detects an execution of ANY command, it will itself check what the command was (using the {LASTSPOKENCMD} and {CMDWHENISAY}). The command string would then be processed by a text analyzer, given specific tags based on keywords and stored in the database with the date it was last executed. It's not for "important" commands - it's for every single command that's ever used.

Now, I see there's no chance for {CMDCOUNT} then. How about the boolean token {CMDEXECUTING}? You didn't say anything about this one.
Or maybe something else. We have the "Execute a command each time a phrase is not recognized". How about an "Execute a (background) command each time a phrase IS recognized" option?

[Gary]

The execute on recognized has been rolled back and forth for a long time, and it gets ugly.  It boils down to when the command gets invoked:  before or after the executing command?  That would mean there should be two 'on recognized' commands- one that can execute before and one that can execute after.  Then, the second (and bigger) problem is that the user wont want these executing every time, or even at all for any or all commands.  So, there would need to be options and handling for all that.

Now that I know why a count is needed in your case, I can put a simple count flag in to count all top-level (non-subcommand) commands to help you along with your project

[PsiQss]

Thank you, Gary

Now that I know why a count is needed in your case, I can put a simple count flag in to count all top-level (non-subcommand) commands to help you along with your project

Sorry for not making that clear before, I thought you did have a look at the link I've posted, where I tried to explain the exact concept of what I want to do with this. Well, I guess it's time to get back to coding, once I have the system in place I'll test out the new options.

Thanks again