Feature request: Kill (by name)

[sthompson]

We now have the ability to execute a command by name, which is very handy when the command in question is in another profile that is going to be included in this one (or along with this one in a common parent). But there does not appear to be any corresponding "kill" command to stop a command by name.

There is a workaround which is to create a command in the same profile as the one to be killed that does nothing but kill that command. Then you can call this new command by name from somewhere else. But it seems like a rather indirect way to do it.


EDIT by Pfeil: This functionality is available using the "Stop by name" option of the "Stop Another Command" action.

[Gary]

This one comes and goes from my list to implement, but it hasn't happened because of the footwork involved, plus overhead.  Each command would need the ability of checking whether or not something else is killing it... *between each and every action*.  This is a time penalty that everybody must incur for a feature that very, very few will ever use.  Probably the best way for now is that if you have that rare stubborn command or two that may need to be killed (long loops, for instance), I would have a variable that's checked within the loop that's set wherever you want to stop it from.  That's basically what would be happening behind the scenes, but not unnecessarily in the background for each and every action in every command. 

Hope that helps!

[sthompson]

So I gather that a "kill by name" feature would mean that every command is constantly checking to see whether it should "die now." Do I have that right? If so then I understand the overhead issue.

I'm a bit puzzled why this isn't a problem already with the existing "kill" command. But I can see that you could use the existence of a "kill" command in the same profile as a signal that the target command needs to check for a "die now" signal, and this would raise the overhead for that command only. So I conjecture that the overhead you mention is still there whenever the kill command is used, but that its extent is limited to only the command that sometimes is killed.

Assuming that I have the correct understanding then the workaround I mentioned in the original post avoids the broader overhead problem. You could build in this same approach as follows: Create a user-settable flag on each command that marks it as "killable." It would be off by default. Turning it on would cause the command to incur overhead since it would have to repeatedly do the checking you mention of its "die now" flag while executing. But only commands that have been specified as "killable" would incur the overhead.

In any event I can see why this might not be a high priority. VoiceAttack is pretty great as is!