Forcing to get Focus of the Window..

[anandnz]

Hi Gurus,

With great help from awesome people here, i managed a script working to close the pop up error windows and successful information.

However, on certain situations the success or error window gets minimized or out of focus because of some administrator activities in the PC and my script detects windows and repeatedly calls function to take action in forever loop.

in success and error window () i use ControlFocus() and i have also tried ControlGetFocus() but these don't focus the windows which comes up for action. What i am looking for is the command, which forces the focus of the window when detected brings it forefront by selecting, so that my scripts work. This command is important to make my script work reliable.

Thank a ton in Advance

--Anand

[John]

Perhaps it is WinActivate you are looking for. It will set focus on the defined window before trying to interact with the windows controls. Though, to be honest, I am not real sure exactly what your situation is.

[anandnz]

Thanks John,

Unfortunately i cannot use WinActivate() as this will not work when PC is locked. Here is my situation, i run the script to handle some of the third party application throws up Modal dialog boxes ( sucess, error etc) whcih requires user action so that license is freed up

for next iteration of document publishing. The errors could be any thing from word to custom built by the third party(badly).

So i got a script which is working ( with great help), however on certain occassions when the Network administrator messages or for some reason the application's dialog boxes goes out of focus and gets minimized, my script detects the dialog boxes and does not work until

i manually set the focus to the desired dialog boxes. This should work when the virtual PC is running remotely. Any help is appreciated.

Regards and Thanks in Advance

-- Anand

[John]

I am still not sure what the situation is, or in what way the PC is 'locked'. I cannot imagine under what circumstances AutoIt would be able to interact with a focused window, yet the same unfocused window be inaccessible. Unless maybe the administrator message is system modal, in which case it must be responded to before anything else can be interacted with. But if you are able to manually focus the dialog I see no reason AutoIt could not do the same. I even use WinActivate() to interact with hidden windows the user cannot even see.

Perhaps WinSetState("Error", "text", @SW_RESTORE) will work? That is what I generally use for dialog boxes. I cannot help but to think I am missing something about the situation. Otherwise there is no reason, even with administrator messages stealing focus, why AutoIt cannot set focus back on the dialog boxes. If these administrative events initiates a series of focus stealing windows you may have to simply keep looping until the administrative task completes and you successfully get focus long enough to control click and close the dialog. I am near certain that if the process getting in the way was understood the solution would follow.

[anandnz]

Thanks John.

When i say PC is locked, it is screen locked because of Idle time. As per company rules, all PC should have screen locked after some idle time.

I was advised to follow this when some of my commands did not work: http://www.autoitscript.com/wiki/FAQ#Why_doesn.27t_my_script_work_on_a_locked_workstation.3F. Hence i was thinking WinActivate() might not work.

When i say Administrator's message, i mean global system updates, maintainence etc. However i have observed over period of testing on several days, my script forever detects presence of window success or fail but waiting forever doing nothing

until next day, i bring to active focus the relevant window which for some reason is minimized. It happens frequently and not always. For reliability sake, i want to ensure that if any of windows i am searching ( small dialog box), i force it to focus so that script is running smoothly.

Please let me know if you got the picture of what i am trying to do.

Thanks in Advance

-- Anand

[John]

You are right. Give me a few minutes to play with it some more.

[anandnz]

Step 1: Open a Notepad and minimize it.

I have tested this code by screen locing PC and by keeping screen alive ..

when screen Alive "Hello" gets printed on the notepad sometimes .. it misses many times..

when PC is locked the misses are very high,... that is a danger to me.. Any help ..

;; This to make sure that Notepad which is minimized is activated and
;; Send("Strings are enetered in the Notepad" )
;;; Open a Notepad and mimimize it after PC is locked and PC not locked.

Sleep(3000); This time delay to enable you to lock your PC.
ControlFocus("[CLASS:Notepad]", "", "") ; works most of the time when PC is locked not always is the concern
Send("HEllo")

[John]

I am not seeing a solution. The ControlClick() even returns successful even though it was not.

Perhaps if you used a mousemove to and from specific pixels to prevent the computer from locking. Then have the script automatically lock the computer when done or if anybody moves the mouse from those specific pixels or taps any keys on the keyboard. That way the computer is 'effectively' locked out, for users, even though it is not so long as the script is the only thing interacting with it. It would mean that running your script effectively locks the computer immediately to any local user input. You could simply throw a messagebox of your own to pause your script upon locking the computer. If the user has the password to get back in they can simply wait till they are done before closing your scripts messagebox for it to continue in the pseudo-locked state, while your script continues. If they fail to resume the script when done the computer will time out and lock normally.

It would at least technically meet the company requirements of locking the computer, while remaining unlocked for the script. Of course, depending on use and circumstances, it may not be workable. That is the best I can think of though. So long as the computer is actually locked I see no way to dependably maintain control of window focus.

[anandnz]

Thanks John. however, the scripts run for several hours over night. Each document takes several hours to publish and i have several to publish so .. some other solution would be welcome.

Thanks in Advance

-- Anand