The "Get User Input - " actions(Text, Choice, Integer, Decimal) windows appear to be intended to steal focus when they're created; The manual doesn't state it explicitly, but that is what I infer from the fact that they do most of the time.
However, this doesn't always happen, regardless of whether the "Stay on Top" option is checked.
From what I can tell, if VoiceAttack is manually given focus, and focus is switch to another application, the created window will fail to steal focus.
If VoiceAttack has focus when the window is created it does gain focus, but as it's a child window of that application that makes sense.
- Click VoiceAttack's main window so it gains focus
- Click another open application so it gains focus
- Execute a command containing a "Get User Input - " action
- Observe that the created window does not gain focus, but is retained by the previously clicked application
- Click the "Cancel" button on the created window
- Execute a command containing a "Get User Input - " action
- Observe that the created window gains focus
- Click the "Cancel" button on the created window
- Click VoiceAttack's main window so it gains focus
- Click another open application so it gains focus
- Click yet another open application so it gains focus
- Execute a command containing a "Get User Input - " action
- Observe that the created window does not gain focus, but is retained by the previously clicked application
- Close VoiceAttack
- Start VoiceAttack
- Click another open application so it gains focus
- Execute a command containing a "Get User Input - " action
- Observe that the created window gains focus
- Click the "Cancel" button on the created window
- Click VoiceAttack's main window so it gains focus
- Click another open application so it gains focus
- Execute a command containing a "Get User Input - " action
- Observe that the created window does not gain focus, but is retained by the previously clicked application
The only difference the "Stay on Top" option makes is that the input control of the created window will *appear* to have focus(I.E. the contents, if any, are highlighted in blue for Integer, Decimal, and Text, and the latter also displays a blinking cursor which stops blinking after a few seconds) when it is checked.
This could be a Windows issue, but perhaps it can be worked around internally.
The "Perform a Window Function" action does not(currently) affect child windows like these, but as the created window gains focus just fine when VoiceAttack has focus, that action can be used to give VoiceAttack focus explicitly before using a "Get User Input - " action.
E.G.
Display window 'VoiceAttack' as [Show]
Get Text Input [test]
However, this will not work if VoiceAttack is minimized to the system tray.
Having the VoiceAttack window in front of the active window may not be desirable, so this could be extended to something like
Set Text [~activeWindow] to '{ACTIVEWINDOWTITLE}'
Display window 'VoiceAttack' as [Show]
Get Text Input [test]
Display window '{TXT:~activeWindow}' as [Show]
to attempt to bring the previously active window back to the top.
As an aside, the "Get User Input - Choice" dropdown looks as if it's grayed out(it's uniform gray rather than a white field with a gray button, like the main window), though it's still interactive.
Also, the created window always appears on the monitor that contains the largest surface of VoiceAttack's main window(E.G. if it's 49 percent on monitor one, it will appear on monitor two because 51 percent of the application window resides there). Would it be desirable to have it appear on the monitor where most of the active window resides, instead?
EDIT: Fixed in v1.8.3.22 (not v1.8.3.21
)
Topic: [v1.7.2.26] "Get User Input - " windows don't always steal focus (Read 3678 times)