[v1.6.1.31] Prefix/Suffix command targeting is ignored

[Pfeil]

When creating prefix and suffix commands, the "Send this command to" and "Stop command if target window focus is lost" options appear to be ignored.

Regardless of whether the options are set in the prefix, suffix, or both, even when the options are identical, focus is not switched to the target window, nor does the command stop when focus is lost.

[Gary]

Ok... I was able to reproduce this.  Looks like a step was missed when we switching over a few months back.  This has been resolved.  Also found the same issue when using, 'Quick Input' (fixed).

Thanks for finding that.

[Pfeil]

I know you've worked hard on the new beta, Gary, but I'm afraid I have to spoil it for you

In v1.6.1.34:

While prefix and suffix can both have the "Send this command to" option set independently, only the prefix's target is used. Even with a second of delay in the suffix, all keypresses are sent to the prefix target, while the suffix target receives none and never gains focus.


Even when both the prefix and suffix command have the "Stop command if target window focus is lost" option checked, switching to a different window does not stop them.
Testing was done thusly:

Code: [Select]

Press Space key and hold for 0,01 seconds and release
Pause 10 seconds
Press Space key and hold for 0,01 seconds and release
within the ten second pause I switched repeatedly between windows that were not the target, yet the command did not stop, either while the prefix command or the suffix command were executing at that point in time.



The following are observed with non prefix/suffix commands:

When the "Send this command to" option is checked, focus changes to the target window when the command runs, as expected. However, when the "Stop command if target window focus is lost" option is checked as well, the command instantly stops when it starts, with a "Stopped command, '' : focus lost" message in the log.

If the "Resume command if target window focus is lost" option is also checked, the command will instead pause immediately; Presumably when focus switches to the target window, this counts as losing focus, as

The focused window is the window that has the focus when the command is first executed.

It's not documented whether it's an intended feature(to prevent commands starting when the correct window doesn't have focus), however the fact that the command can pause and start immediately(and possibly unexpectedly, depending on when and how many instances of the command were issues when out of focus) when the target window is focused, I feel it may not function entirely as expected.


Commands that are paused when the "Resume command if target window focus is lost" option is checked, are not stopped when the "Stop commands"  button is clicked, or the "Make VoiceAttack Stop Processing All Commands" action runs. Instead, the command resumes and immediately stops only when the target window regains focus.

[Gary]

While prefix and suffix can both have the "Send this command to" option set independently, only the prefix's target is used. Even with a second of delay in the suffix, all keypresses are sent to the prefix target, while the suffix target receives none and never gains focus.

I thought I had it documented that prefix commands override certain aspects of suffix commands (unless the prefix isn't set... only in certain cases... I can't even remember what... it's been a very long time).  I guess I need to look into that.  Behind the scenes, there is only one command executing.  It's not really one command and then another command.  It's a composite command made up of both the prefix and suffix.  Surprised this hasn't come up until now lol.

It's not documented whether it's an intended feature(to prevent commands starting when the correct window doesn't have focus), however the fact that the command can pause and start immediately(and possibly unexpectedly, depending on when and how many instances of the command were issues when out of focus) when the target window is focused, I feel it may not function entirely as expected.

I've changed it up so that if the process is not, 'active window' (of course), do not pause if the command was just initiated.
It will try to focus the target as normal and only pause if the focus is lost after that.

Commands that are paused when the "Resume command if target window focus is lost" option is checked, are not stopped when the "Stop commands"  button is clicked, or the "Make VoiceAttack Stop Processing All Commands" action runs. Instead, the command resumes and immediately stops only when the target window regains focus.

Ah... gotcha.  This was an easy one to fix.


As always, hat's off to Pfeil's master VA skills

[Gary]

I put a build out in the, 'unofficial' bin if you don't want to wait til the next beta... http://www.voiceattack.com/unofficial

[Pfeil]

I thought I had it documented that prefix commands override certain aspects of suffix commands

I looked at the "Send this command to" subsection of the "Command Screen" section, and the "Application Focus (Process Target) Guide" section, neither of which reference prefixes.

I also did a search throughout the document for "prefix", however I could not find any reference to that behavior(I'm not claiming it doesn't exist, just that I didn't find it).

I put a build out in the, 'unofficial' bin

I did some testing with that build:

I've changed it up so that if the process is not, 'active window' (of course), do not pause if the command was just initiated.
It will try to focus the target as normal and only pause if the focus is lost after that.

When the "Send this command to" option within a command is used, but no input-generating action(I.E. anything that needs window focus to interact with the target) is present in the command, focus will not change, and the command will still pause or stop immediately if "Stop command if target window focus is lost" is checked and the target is not in focus.
This is not true when the "Send commands to" feature on the main screen(or the same feature in the Profile Options) is used; Focus will be switched to the given target, regardless of the contents of the command.



Part of the original issue still appears to be present in v1.6.1.35; When focus is lost, the command still keeps going, despite the "Stop command if target window focus is lost" option set in prefix, suffix, or both.



If Quick Input is running when a command(normal, as I can't test with prefix/suffix) is stopped or paused, it will display a GUID(which changes with each instance of the command) in the log rather than the command name(though behaves as expected aside from that).

[Gary]

When the "Send this command to" option within a command is used, but no input-generating action(I.E. anything that needs window focus to interact with the target) is present in the command, focus will not change, and the command will still pause or stop immediately if "Stop command if target window focus is lost" is checked and the target is not in focus.

Ah.  I'm seeing the disconnect now.  I'm going to put back the pause immediately if the command is called when the target is not focused.  This was the intent from the start, as otherwise, aside from when input is occurring (where focus is required), the target app must be forced into focus in order for this to work and that would NOT be what one would expect (especially when there is either no input, or the input does not occur until later in the command).  It needs to be thought of more as it's not going to do anything unless the target is focused by the user (and not done by VA).

Thanks for the help on that.  It's rather fun to dig into the deep, dark details from time to time.

Part of the original issue still appears to be present in v1.6.1.35; When focus is lost, the command still keeps going, despite the "Stop command if target window focus is lost" option set in prefix, suffix, or both.

I think I've got this one wrapped up now.

If Quick Input is running when a command(normal, as I can't test with prefix/suffix) is stopped or paused, it will display a GUID(which changes with each instance of the command) in the log rather than the command name(though behaves as expected aside from that).

Aha... I see it.  Good catch (fixed).

I put a build out in, 'unofficial' if you want to try it out:  http://www.voiceattack.com/unofficial

[Pfeil]

Seems to be working with v1.6.1.37.

One caveat to note is that commands will not stop or pause during a pause action.


There also appears to be something amiss with the running command detection after commands are stopped by the "Stop command if target window focus is lost" option:
When closing the "Edit a Profile" window, it will pop up the "Editing running commands can cause conflicts" message, however no "Stopped command, ''" entry appears in the log.

Steps to replicate:

• Create a command, add some action so it runs long enough for the window focus to be manually changed
• Check the "Stop command if target window focus is lost" option
• Save the command, save the profile
• Run the command
• Click another window or otherwise change window focus
• Note that the command stops, and a "Stopped command, '' : focus lost" entry appears in the log
• Open the "Edit a Profile" window, then open any command for editing
• Click "OK"(no need to make actual changes, as the "edited" flag appears to be set by the button)
• Click "Done"
• Note that the "Commands Running" dialog appears
• Click "Yes"
• Note the lack of a log entry regarding the stopping of commands
• Repeat steps 7 to 9
• Note that the "Commands Running dialog does not appear any longer

[Gary]

One caveat to note is that commands will not stop or pause during a pause action.

I started on a reply about this earlier, but somehow switched to the other stuff. 

Pauses are a special case in which there is nothing else going on to try to keep the timing as close to what is indicated as possible.  The check is done after the pause completes, just for that.  The important thing is that nothing else executes that is actually doing anything AFTER the pause, and people are usually not watching their logs while they are doing stuff so I don't think it hurts to have it continue to be this way.  The alternative would be to spawn a separate watcher thread, but I think that adds a little too much overhead and time penalty for that type of situation (checking variables to see if we need to create a watcher thread for what is ultimately a .01 second pause).

There also appears to be something amiss with the running command detection after commands are stopped by the "Stop command if target window focus is lost" option:
When closing the "Edit a Profile" window, it will pop up the "Editing running commands can cause conflicts" message, however no "Stopped command, ''" entry appears in the log.

Thanks for the heads-up on that.  It was just not clearing a flag in that type of situation.  All sorted now.


There's a build out in, 'unofficial':  http://www.voiceattack.com/unofficial
It's just got this flag fixed and the, 'pink' log icon thing...

[Pfeil]

people are usually not watching their logs while they are doing stuff so I don't think it hurts to have it continue to be this way.

If the command does not have the "Allow other commands to be executed while this one is running" option enabled, it does mean that no commands can be executed during that pause, though it's probably unlikely to be a big issue in real-world usage.


v1.6.1.38 looks to be working fine in the flag-clearing department.