Jump to content

Windows problem or autoit problem with windows detection?


Recommended Posts

Basic windows detection and automation of the replace/skip file window that pops up on transfer conflicts does not work consistently. The window has no detectable or hidden text, just title and class. I've tried all the detection modes.

Now the problem. Basic script to test for it's existence then do a send key automation to skip the file will work a few times. Then at a random point it will consistently see the window, even though it is not actually visible, and loop the automation continuously like the window is hidden or something. Then when I force the window to actually pop again by transferring another duplicate file, the automation set to go doesn't actually act on the now visible window, as if it's not seeing the now visible window and instead focused on a hidden window (assumption). The only remedy for this is to send out a winkill(), and when I do that it's like the whole desktop resets...I've never really seen something like that before.

Again, simple automation will make this happen at random, could be the 10th time or 100th time. The only way to consistently make it happen is to close the skip window by ways of the red X instead of making a selection.

Any input? As of now my solution is to send a winkill() at the start of the app in case this window is hidden, and a winkill() after the skip file automation. I don't like how it seems to reset (blank out for a couple seconds) the desktop, I don't know if that's doing something to my system so I'm looking for another solution.

Link to post
Share on other sites

This worked for me. It wont see the hidden window that gets created, but when a new one pops up it will act on it, and end up canceling out the one that is hidden. Best thing it gives me the opportunity to act on some other information this dialog presents that I wanted to use and thought there was no way.

 

Thanks.

 

EDIT:

Only issue is I have this in the main loop:

$oDesktop.FindFirst( $TreeScope_Children, $pCondition, $pWindow1 )
    $oWindow1 = ObjCreateInterface( $pWindow1, $sIID_IUIAutomationElement, $dtagIUIAutomationElement )

Instead of just:

If IsObj( $oWindow1 ) Then Example()

Which is taxing me 5% on the CPU, but I guess I can deal with that. Other option is to use the winexist to detect it, and then this to click the button. I'll see how it goes with this for a while if that 5% interferes with the more taxing stuff I do.

Edited by Champak
Link to post
Share on other sites

Why not checking if its visible (appearently you only want to act when its visible)

https://www.autoitscript.com/autoit3/docs/functions/WinGetState.htm

Besides WinKill maybe just try

  • WinGetPos to find out the location where it is
  • WinMove to 0,0 the left top so you really now where to look
  • WinSetOnTop to make sure it becomes a topwindow
  • WinSetState to make it visible 
  • WinFlash to make sure you see where it is
  • ...
  • UIA is slower then the Win* functions as its a much bigger library

The window could be anywhere behind something else or on a different desktop if you use multiple monitors.

But maybe better to first check if a file exists to prevent duplicate popup at all

 

Link to post
Share on other sites

You gave me a good idea with the wingetstate. Using that with winexist allows me to use the UIA in the main loop without constantly hitting it. Now I use winexist and wingetstate(visible) to detect the window, then use the UIA so now things move faster without taxing the CPU unnecessarily and I have access to other information, thanks.

When the window goes invisible it doesn't go anywhere else, just stays there invisible. And when I set it back to visible, it can't be closed out normally anymore even with the X button, it has to be killed.

Either way, all is working in an acceptable way for me now.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...