[V1.5.8.20] Cannot close command list while command(s) are running

[Pfeil]

While a command is running (tested with a pause or TTS with "Wait until speech completes before continuing command" checked), it's impossible to close to command list, either by clicking "Done" or "Cancel", unless said command has "Allow other commands to be executed while this one is running" checked.

Other buttons remain functional, commands can be created, and the "Confirm Close" dialog pops up if anything has been modified/added when "Cancel" is clicked, but the actual command list window will only close after the command has finished executing.


Regardless of there being an underlying reason for keeping the list open, providing no feedback(such as a simple "Please wait until commands have finished" dialog, possibly with a "Force stop" option) is potentially frustrating for a user that isn't aware of this behaviour.

[Gary]

I'll see what can be done about that.  Thanks for the heads-up.

[Gary]

This should be resolved in the next release

[Gary]

New beta is out there that addresses this and also adds an option on what to do with blocked commands:

http://www.voiceattack.com/beta

[Pfeil]

Resolved, but with a caveat:

If a command is paused when the command list is opened and closed(modifying the profile or not, "Done" and "Cancel" exhibit the same behavior), the command will be stopped, but only after the pause is done.

This means any commands after the command list is closed will have to wait for the pause to elapse(if "Allow other commands to be executed while this one is running" isn't checked), or be blocked entirely(depending on "Cancel blocked commands" setting), even though the paused command won't actually do anything aside from logging "Stopped command" after said pause is complete.

[Gary]

Unfortunately there is no additional checking within a, 'pause' as that can affect pause timing.  So, during a pause, it doesn't check to see if something has been edited or if another command is running or if listening is on or anything else other than just a full stop.

[Pfeil]

What I feel is the problem is that the "full stop" only occurs after the pause has finished. The "Stop Commands" UI button will kill any and all commands immediately, even during a pause, so I'd assume you can do the same when the command list is closed.

[Gary]

This brings up a new point.  The way things work now is that there probably wouldn't even be a need to stop running commands when the editor is opened.  The running commands wouldn't be affected (the root commands at least... any subcommands would reflect the change).  I think another user asked for that a while back in the Google group.  This may only require a single change (famous last words) and maybe a warning box.

[Pfeil]

I do seem to recall someone asking about that, in the context of not interrupting running loops, if I remember correctly.

A warning would make sense when editing running commands, especially when they're in an infinite loop.

For commands using actual loops(Not jumps to create a loop, unless you want to build in detection for that), maybe a "Would you like to restart this command?" dialog would be useful.

[Gary]

New beta is out there.  This should cover it

There is an option to stop the command or not on save.  I didn't add a, 'continue' or a 'restart' as there's too much going on and you never know what state a command was in when you stop it (it could cause more trouble than it's worth), so I gave up on it.  Good suggestion, though.

[Pfeil]

I unchecked "Stop Running Commands When Editing", but when I click "Done"(Not "Cancel"), even without changes, any running commands are stopped regardless(Though now they are stopped immediately, rather than after a pause).

Even after a restart, the behavior appears the same, with the box checked or not. The only difference I can see is the dialog window popping up(when unchecked) after an edit, asking whether I want to stop running commands, which it proceeds to do whether I click "Yes" or "No".

[Gary]

Yup... you are right.  I'm kind of bent on optimizing some things and this got broken in the process

Thanks for catching that... it was working right at one point.

I moved even more stuff around to speed things up, so I'm hoping it didn't mangle something else.

[Pfeil]

'Stop Running Commands When Editing' might work this time... maybe.

If the option is checked, running commands are stopped the moment the command list opens as expected, but commands cannot be executed while the list is open. Neither through voice recognition, or using the context menu.

This does not occur of the option is unchecked.

[Gary]

If that box is checked, commands should not be running at all when the editor is open.  There shouldn't be a mix of both in my opinion.  The commands either need to be off or on when editing.

Given that, is this done?

[Pfeil]

If that box is checked, commands should not be running at all when the editor is open.

Ah. In that case it appears to be done.

I had assumed you wanted to switch between previous behavior and no stopping, instead of always stopping or not.

[Gary]

I had to pick one... it gets kind of squirrelly if I don't (I would probably need to add another option).

[Gary]

I would say that running a command while the editor is open should be alright even if that setting is checked, however, the idea behind it is more of a safeguard that things will be stopped completely before allowing edits.  I mean, we've got our big boy pants on and really... what's the worst thing that can happen if a subcommand is executing after being edited?  It's almost like the default should be that it's not checked and everything just freely runs... but, if you are paranoid that something might happen you can check that box.   Probably just going to make it unselected by default.

[Gary]

The latest beta leaves this option off by default.