Posted Wed, 30 Oct 2019 14:52:33 GMT by

Been using Automate 10.4 for years.. getting ready to move to Automate 11.1.30.3 as the existing 10.4 install's Server 2008 OS approaches EOL in January.

I have a task that launches an in-house proprietary terminal client, focuses its window and then inputs keystrokes into that window. It works fine in Automate 10.4, but if I invoke the task from the Task Administrator in Automate 11, the terminal client is invoked, but even with a focus statement, the window isn't brought to the foreground, and the timeout for the interaction is reached.

I've tried using the window title (what worked originally) and the window class to target, but neither works

<AMPROCESSES ACTIVITY="create" EXECUTABLE="REDACTED.EXE" WORKINGDIR="REDACTED" ARGUMENTS="/SETTINGS_DIR=REDACTED /WORK_DIR=REDACTED /VHOST=REDACTED" PRIORITY="normal" />
<AMWAIT SCALAR="10" />
<AMWINDOW WINDOWCLASS="TTMW" ACCESSIBILITYENGINE="active" CONTAINSOBJECT="YES" OBJECTPROPERTYSETS="Toolkit=WindowsAccessibility,Type=ClientArea,Class=TTerminalWin,Name=Terminal_AU2,Value=,X=,Y=" ALLOWHIDDEN="YES" />
<AMWINDOW ACTIVITY="maximize" WINDOWCLASS="TTMW" ACCESSIBILITYENGINE="active" CONTAINSOBJECT="YES" OBJECTPROPERTYSETS="Toolkit=WindowsAccessibility,Type=ClientArea,Class=TTerminalWin,Name=Terminal_AU2,Value=,X=,Y=" ALLOWHIDDEN="YES" />

... the app window launches, sometimes it flashes, but the Task Administrator always "stays on top". Similar for the task editor. I can manually go and click on the launched application window, and then it's targeted fine - but it feels like there's some sort of barrier between Automate and the terminal client.

OS is Server 2016 Datacentre in an Amazon t3.large instance.

Any ideas what's blocking focus of the window?

Errors received are all:

Error message: Window cannot be focused

 

Posted Wed, 30 Oct 2019 21:17:57 GMT by

Hi Anthony,

The most likely cause of this issue would be that the Windows Foreground timeout is enabled on the machine. To disable via Automate, navigate to Options/System Settings and open Execution. There is a check box to disable this setting. If the box is unchecked, please check it and click Apply. If this setting is left unchecked it will cause the Window and Interactivity set of actions to fail. Please note that this is a system setting, and depending on your Policy settings may be reset on restart of the machine.

If this does not resolve the issue, would it be possible to set-up a remote support session where we can take a closer look at this issue? If this is possible please send an email over to [email protected] with a list of your availability. In the email, also please verify the Operating System of the machine in question and it's bit level, as well as the version and bit level of the AutoMate software.
Note: Please reference this forum thread in your email.

Posted Thu, 31 Oct 2019 09:18:56 GMT by

That looks like it's working, Justin! ... Thanks!

Hopefully IT haven't put in a GPO to reverse it (though I did try a gpupdate /force after applying it)..

Posted Thu, 31 Oct 2019 09:21:48 GMT by

For those curious:

Posted Mon, 04 Nov 2019 14:05:51 GMT by

Which policy setting would reset this particular option?

Eg. What's it called in GPO Editor?

I suspect it may be subject to a policy, as I found it turned back on again :-/

Posted Mon, 04 Nov 2019 14:11:16 GMT by

Can I confirm the registry entry is HKCU\Control Panel\Desktop\ForegroundLockTimeout ?

Posted Tue, 05 Nov 2019 00:14:29 GMT by

Hello Anthony,

Yes, that is the default/normal location where this setting is configured, however there may be additional locations due to the security level of your environment. Unfortunately it is difficult to say with certainty that this is the correct location, as virtually every customer environment is different.

Posted Tue, 12 Nov 2019 11:02:49 GMT by

I have a task that runs every five minutes of idle time to move the mouse and toggle scroll lock :)

... I've added registry update to that which seems to be reapplying frequently enough that we've had no more problems.

AMREGISTRY ACTIVITY="write_value" KEY="HKEY_CURRENT_USER\Control Panel\Desktop" VALUE="ForegroundLockTimeout" VALUEDATA="0" TYPE="dword"
Posted Tue, 14 Apr 2020 17:44:23 GMT by

A recent Windows update installed by IT department has caused this problem to come back again. Has anyone else had issues recently with Automate refusing to interact with applications its launched itself on a schedule?

Posted Thu, 16 Apr 2020 05:58:57 GMT by

Hello Anthony,

Is it possible to let us know which update(s) were installed that caused the issue?

Posted Thu, 21 Sep 2023 12:59:38 GMT by Elizabeth Mathew
Yes we are having the same issue and use version Automate 10. Tasks are always failing at the focus window mode step. Was this resolved at all ?

You must be signed in to post in this forum.