Minimized window then use WinActivate and it brings up the window but window then becomes not active

Question

I'm using WinActivate and I am able to bring up the window but the window then becomes not active / selected (the title bar in the window is grayed instead of the dark blue or bright color when the window is selected). I would need to click on the window and manually perform the next step in the macro before the rest of the macro will run. Sometimes when I run the macro it runs perfectly and the window comes up and stays activated. But other times the macro stalls after the window is brought up but I notice the window is not really selected/activated (the title bar of the window dims with the appearance similar to when I click outside the window). I've tried WinRestore and still getting the problem.

I think the macro works when the window I want to activate is not minimized. But if I minimize the window and then run the macro, the winActivate will bring the window up but the title bar of the window is gray like the window is not active. The macro will stall until I click on the window and manually complete the next step in the macro. I've tried to left click on the window after the window is brought up but for some reason it doesn't work and the macro will not activate the window and stall until I click on the window and manually complete the next step in the macro (it is like the macro treats it like I didn't even add the extra step to click on the window).

Answer 1

Windows do not always behave equally. Sub Windows that are generated by a parent window are occasionally erratic. Commands will not always work. ControlClick seems to be particularly susceptible to trouble.

When working with multiple windows it is best to do the WinActivation then immediately perform the next step. Just moving your mouse around the screen while the script is running could interfere with the script commands.

Occasionally, when the ControlClick command behaves erratically I move the mouse cursor over the desired button first then do the ControlClick.

Sometimes I have to find the desired button location then do a mouse click at the x, y location of the button. I also use the BlockInput On and BLockInput Off commands before and after the WinActivate and button click commands. Make sure you do not put a BlockInput On inside a loop unless it is followed by a BlockInput Off inside the same loop. If you get stuck in the loop after a BlockInput On you are locked out and may have to reboot the PC to get out of it.

If a WinActivate does not work properly you can locate the window's position and then calculate a blank spot on the title bar and do a mouse click.

I have always found an alternative method to an erratic command. I just dive into the manual and find the hard way to get it done. I wrote a small script a few days ago that used the Control commands. It worked perfectly the first day then died. I ended up rewriting it with what most here would consider as Neanderthal code but it works, and Grog be happy. :)

Answer 2

I have a problem with a minimized window in one particularly badly behaved program. The window does not minimize to the PC's taskbar at the bottom of the screen. It minimizes to the bottom of the parent window that opened it. A WinMinimize command works to minimize the window to the bottom of the parent but a WinActivate doesn't bring it back up. The only way to bring the window back up is to click on the minimized window's Titlebar button.

Rather than minimizing the window in the script I move it down to the bottom of the screen out of the way then move it back up when I need it.

Another problem I had with this first sub window was I couldn't close it if a second sub window had been opened by the parent. The second sub window must be closed before the first sub window can be closed.

If you use a WinWaitActive command it will lock up the script if the desired window does not activate unless you specify a max wait time. Check the manual for the correct syntax.

Sometimes all you can do is to automate a procedure exactly the way you do it manually with mouse clicks at the appropriate location.

That can get very complicated because you often have to verify the x, y position of a click and that an action has been completed before moving on to the next step.

You can't always depend on a sleep statement delay. Occasionally things just take their own sweet time to happen. Longer than the sleep statement's time that usually is enough and your script is locked up solid.

I usually look for a change to take place after a click. Sometime it is a change in the button's enable/disable status or another button's enable/disable status. Sometime it's a new window popping up or another window minimizing/closing.

If you miss one small detail you're history.

I always put ToolTip progress description messages on the screen. At least when something unusual happens I can see where the problem exists in the script.

I have an Observatory in my back yard that is fully automated with AutoHotKey scripts. Four computers, seven cameras and a cabinet full of electronics out there controlled by a PC in the house.

You want to see something scary take a look at this video. It is the observatory automated start up procedure which is initiated by one script running on the house PC. The script powers up the observatory equipment then starts additional scripts on all of the observatory computers when they have booted up.

https://www.youtube.com/watch?v=UN4VoOKOcXo&feature=youtu.be

What I learned in building all this up is you can't trust Windows and most of the apps running in it. Sooner or later one of them will bite you. When you are in a can of worms like mine it's often hard to find the worm with teeth.