Champak Posted November 29, 2021 Share Posted November 29, 2021 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 comment Share on other sites More sharing options...
crackdonalds Posted November 29, 2021 Share Posted November 29, 2021 You're probably killing explorer.exe with the winkill. that's why it seems as if everything resets. Perhaps you can use imagesearch to detect the window instead. Link to comment Share on other sites More sharing options...
Earthshine Posted November 29, 2021 Share Posted November 29, 2021 (edited) You will have to use UI automation to interact with explorer. Standard auto IT will not work because file explorer is not written using older Win32 libraries Edited November 29, 2021 by Earthshine My resources are limited. You must ask the right questions Link to comment Share on other sites More sharing options...
Champak Posted November 29, 2021 Author Share Posted November 29, 2021 Thanks, I'll look into it. Link to comment Share on other sites More sharing options...
Earthshine Posted November 29, 2021 Share Posted November 29, 2021 Look for the threads by @LarsJ. He has all the examples you need. My resources are limited. You must ask the right questions Link to comment Share on other sites More sharing options...
Champak Posted November 29, 2021 Author Share Posted November 29, 2021 (edited) 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 November 29, 2021 by Champak Link to comment Share on other sites More sharing options...
junkew Posted December 1, 2021 Share Posted December 1, 2021 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 https://www.autoitscript.com/autoit3/docs/functions/FileExists.htm https://www.autoitscript.com/autoit3/docs/functions/FileMove.htm FAQ 31 How to click some elements, FAQ 40 Test automation with AutoIt, Multithreading CLR .NET Powershell CMDLets Link to comment Share on other sites More sharing options...
Champak Posted December 5, 2021 Author Share Posted December 5, 2021 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 comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now