WinActivate doesn't reliably work in Windows 10 SAC, recent cumulative

[LisaUoL]

We use AutoIt as part of our Windows deployment process, to automate things that are otherwise not automatable. It's very much a last resort; there aren't many things that require it, but one of them is the installation of drivers that are not signed and Windows therefore won't install without popping up a dialogue.

We use WinActivate to activate these windows and send them keystrokes. This has worked without a problem for years. Suddenly, it's not working. It can't activate the named windows, and when asked whether the window is active, it returns 0, indicating that it's not.

If we click on any other window that's running – or the desktop – suddenly it works. (I.e. my activation loop succeeds on the next try.)

The problem appears to happen on SAC, not LTSC, and it appears to have begun with the July or August cumulative.

Not all computers have the problem, but we have been unable to identify anything in common about the ones that do; they span many different models and ages, and sometimes are identical to other machines that don't have the problem.

Has anyone else noticed this inability to activate windows? Any idea where it's coming from or what we can do? Because obviously, we can't activate our way out of the problem.

One more thing I'll mention: watching an affected machine, the main window of our installer process is itself not in the foreground – i.e. not active – when it launches. This is unusual and may be related, as I understand that the underlying API calls may not allow applications to change what's in the foreground unless they themselves are either in the foreground or were launched by something that was in the foreground. But we also don't know why the main window would not have been in the foreground. Nothing else was running! But this may all be a red herring and completely unrelated.

Thanks,
Lisa.

[Zedna]

As workaround try to use ControlSend() instead of Send() if possible.

[junkew]

Most likely there is somewhere another modal dialog around (or a 2nd desktop?) that prevents you from activating something else and that modal goes away as when you click the desktop

Hard to say but I would suggest for debugging

* use controlxx functions

* add a winactivate for the desktop to first activate the desktop  (below by using shell application)

$oShell = ObjCreate("Shell.Application")
$oShell.ToggleDesktop()

or probably

winactivate("[classname:#32769]","")

* See what winmove is doing with your window

* Use winlist to dump all titles that are on screen

* Loop through winlist items and set them all 1 by 1 active and see whats happening (offcourse for debugging)

* Alternative: Get your window x,y position and move the mouse and click (this assumes its on foreground)
https://www.autoitscript.com/autoit3/docs/functions/MouseMove.htm
https://www.autoitscript.com/autoit3/docs/functions/MouseClick.htm

 

[Earthshine]

are you running with Admin privs?

[LisaUoL]

Wow, I had no idea people were replying! Unfortunately I assumed "following" meant that it would email me if there were replies. Anyway, we have tried the mouseclick suggestion and that has done the job, so thanks! I will mark that as the solution.

Thanks,
Lisa.

[Melba23]

LisaUoL,

If you click on the "Notifications" icon (the bell at top right of the page) you can set how you wish to be notified by the forum.

M23