Sign in to follow this  
Followers 0
TheGimp

WinWait doesn't recognize a window until I move it

10 posts in this topic

#1 ·  Posted (edited)

Hello, I'm experiencing a very weird behavior of the the WinWait function: when the window I'm looking for opens, WinWait doesn't recognize it despite the class, title and visible text parameters being passed correctly to the function. Then, if I move the window WinWait is looking for, WinWait finds it instantly.

This is the code:

Const $GenericSFCWindow = "[TITLE:Protezione file Windows; CLASS:#32770]"
Const $SFCMainWindowText = "Attendere la verifica che tutti i file protetti di Windows siano intatti e nella versione originale."
Const $SFCInsertDiscText = "I file necessari per la corretta esecuzione di Windows devono essere copiati nella cache della DLL."
Const $SFCCancelInsertDiscConfirm = "Se l'operazione viene annullata, più avanti potrebbe essere richiesto l'inserimento di un CD. Ignorare il file?"

Run("SFC.EXE /SCANNOW")
WinWait($GenericSFCWindow, $SFCMainWindowText, 120)
Do
If ((WinExists($GenericSFCWindow, $SFCInsertDiscText) == 1) OR (WinWait($GenericSFCWindow, $SFCInsertDiscText,5) == 1)) Then
    ControlClick($GenericSFCWindow, $SFCInsertDiscText, 2)
    If WinWait($GenericSFCWindow,$SFCCancelInsertDiscConfirm,60) == 1 Then
        ControlClick($GenericSFCWindow,$SFCCancelInsertDiscConfirm,6)
        WinWaitClose($GenericSFCWindow,$SFCCancelInsertDiscConfirm)
    Else
        MsgBox(1, "Errore nell'automazione ricostruzione del database SFC", "Si è verificato un errore durante l'automazione della ricostruzione del database SFC: la finestra di conferma annullamento inserimento disco non è stata trovata.")
        Exit 1
    EndIf
    WinWaitClose($GenericSFCWindow, $SFCInsertDiscText)
EndIf
Until WinExists($GenericSFCWindow,$SFCMainWindowText) == 0

The script's scope is to run "SFC /SCANNOW" and close all the "Insert windows XP disc" windows that appear. The WinWait that is not working is the WinWait($GenericSFCWindow, $SFCInsertDiscText,5) inside the first IF block, all the others work fine.

I was wondering if there was any sort of window title/text caching AutoIT does that could cause this because maybe the SFC dialogs are localized with the text in the dialog being inserted after the dialog appeared and AutoIT doesn't see the new title/text until the window state changes (I.E. it's moved).

Edited by TheGimp

Share this post


Link to post
Share on other sites



Why not just use the text of whatever changed to get the focus then


Contact via MSN: [email=terarink_msn@hotmail.com]terarink_msn@hotmail.com[/email], yahoo: terarink_yah

Share this post


Link to post
Share on other sites

Why not just use the text of whatever changed to get the focus then

The window WinWait is waiting for is the one that gets the focus, I made sure it had focus by clicking on its titlebar however WinWait detects that window only when it's moved. Very weird muttley

Share this post


Link to post
Share on other sites

WinWait ( "title" [, "text" [, timeout]] )

just WinWait("SAME_TITLE", "NEW_TEXT", 60000)


Contact via MSN: [email=terarink_msn@hotmail.com]terarink_msn@hotmail.com[/email], yahoo: terarink_yah

Share this post


Link to post
Share on other sites

WinWait ( "title" [, "text" [, timeout]] )

just WinWait("SAME_TITLE", "NEW_TEXT", 60000)

It doesn't work, the text I put in the winwait is the final text I see in the window (the same I got it with the Window Info Tool) and is 100% correct, otherwise the window wouldn't be detected at all, not even when I move it. weird, huh? muttley

Share this post


Link to post
Share on other sites

Hello, I'm experiencing a very weird behavior of the the WinWait function: when the window I'm looking for opens, WinWait doesn't recognize it despite the class, title and visible text parameters being passed correctly to the function. Then, if I move the window WinWait is looking for, WinWait finds it instantly.

This is the code:

Const $GenericSFCWindow = "[TITLE:Protezione file Windows; CLASS:#32770]"
Const $SFCMainWindowText = "Attendere la verifica che tutti i file protetti di Windows siano intatti e nella versione originale."
Const $SFCInsertDiscText = "I file necessari per la corretta esecuzione di Windows devono essere copiati nella cache della DLL."
Const $SFCCancelInsertDiscConfirm = "Se l'operazione viene annullata, più avanti potrebbe essere richiesto l'inserimento di un CD. Ignorare il file?"

Run("SFC.EXE /SCANNOW")
WinWait($GenericSFCWindow, $SFCMainWindowText, 120)
Do
If ((WinExists($GenericSFCWindow, $SFCInsertDiscText) == 1) OR (WinWait($GenericSFCWindow, $SFCInsertDiscText,5) == 1)) Then
    ControlClick($GenericSFCWindow, $SFCInsertDiscText, 2)
    If WinWait($GenericSFCWindow,$SFCCancelInsertDiscConfirm,60) == 1 Then
        ControlClick($GenericSFCWindow,$SFCCancelInsertDiscConfirm,6)
        WinWaitClose($GenericSFCWindow,$SFCCancelInsertDiscConfirm)
    Else
        MsgBox(1, "Errore nell'automazione ricostruzione del database SFC", "Si è verificato un errore durante l'automazione della ricostruzione del database SFC: la finestra di conferma annullamento inserimento disco non è stata trovata.")
        Exit 1
    EndIf
    WinWaitClose($GenericSFCWindow, $SFCInsertDiscText)
EndIf
Until WinExists($GenericSFCWindow,$SFCMainWindowText) == 0

The script's scope is to run "SFC /SCANNOW" and close all the "Insert windows XP disc" windows that appear. The WinWait that is not working is the WinWait($GenericSFCWindow, $SFCInsertDiscText,5) inside the first IF block, all the others work fine.

I was wondering if there was any sort of window title/text caching AutoIT does that could cause this because maybe the SFC dialogs are localized with the text in the dialog being inserted after the dialog appeared and AutoIT doesn't see the new title/text until the window state changes (I.E. it's moved).

I don't know the cause of your exact problem, but I find the construction of your loop to be odd.

As I recall, when you run SFC and the "insert disc" windows appears, if you click the "cancel" button, then the "confirm cancel" window will always appear. So the main loop would be more like this:

While WinExists($GenericSFCWindow, $SFCMainWindowText)

    If WinExists($GenericSFCWindow, $SFCInsertDiscText) Then
        ControlClick($GenericSFCWindow, $SFCInsertDiscText, 2)
        WinWait($GenericSFCWindow, $SFCCancelInsertDiscConfirm)
        ControlClick($GenericSFCWindow, $SFCCancelInsertDiscConfirm, 6)
        WinWaitClose($GenericSFCWindow, $SFCCancelInsertDiscConfirm)
    EndIf

WEnd

I can't figure out what circumstances would lead to the MsgBox(1, "Errore nell'automazione ricostruzione del database SFC"... but I'm sure you could fit it into the simpler loop where you need it.

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

I don't know the cause of your exact problem, but I find the construction of your loop to be odd.

As I recall, when you run SFC and the "insert disc" windows appears, if you click the "cancel" button, then the "confirm cancel" window will always appear.

That was just additional code I put to find out why it wasn't working. I tried your code but the script still exhibits the same behaviour: unless I move the window it doesn't get recognized.

I can't figure out what circumstances would lead to the MsgBox(1, "Errore nell'automazione ricostruzione del database SFC"... but I'm sure you could fit it into the simpler loop where you need it.

Yeah that was useless: it was a sort of assert to make sure the confirm window was opening, to know if the button was clicked or not.

I changed the code to this:

Const $GenericSFCWindow = "[TITLE:Protezione file Windows; CLASS:#32770]"
Const $SFCMainWindowText = "Attendere la verifica che tutti i file protetti di Windows siano intatti e nella versione originale."
Const $SFCInsertDiscText = "I file necessari per la corretta esecuzione di Windows devono essere copiati nella cache della DLL."
Const $SFCCancelInsertDiscConfirm = "Se l'operazione viene annullata, più avanti potrebbe essere richiesto l'inserimento di un CD. Ignorare il file?"

Run("SFC.EXE /SCANNOW")
WinWait($GenericSFCWindow, $SFCMainWindowText, 120)
Do
    If ((WinExists($GenericSFCWindow, $SFCInsertDiscText) == 1) OR (WinWait($GenericSFCWindow, $SFCInsertDiscText, 1) == 1)) Then
        ControlClick($GenericSFCWindow, $SFCInsertDiscText, 2)
        WinWait($GenericSFCWindow,$SFCCancelInsertDiscConfirm,60)
        ControlClick($GenericSFCWindow,$SFCCancelInsertDiscConfirm,6)
    EndIf
Until WinExists($GenericSFCWindow,$SFCMainWindowText) == 0

and I made a video of the strange WinWait behavior that I'm experiencing and put it here. Most of the times the window is detected only after I move it. I'm starting to wonder if the cause is SFC using 100% of the CPU while it's running.

Edited by TheGimp

Share this post


Link to post
Share on other sites

OK, somethimg strange is going on here.

When I run a modified version of my loop (inserting a sleep as well)

Run("SFC.EXE /SCANNOW")
WinWait($GenericSFCWindow, $SFCMainWindowText);, 120)
ConsoleWrite("1) Initial Window appeared" & @CRLF)
While WinExists($GenericSFCWindow, $SFCMainWindowText)

    If WinExists($GenericSFCWindow, $SFCInsertDiscText) Then
        ConsoleWrite("2) InsertDisc Window appeared" & @CRLF)
        ControlClick($GenericSFCWindow, $SFCInsertDiscText, 2)
        WinWait($GenericSFCWindow, $SFCCancelInsertDiscConfirm)
        ConsoleWrite("3) Cancel Insert Disc Window appeared" & @CRLF)
        ControlClick($GenericSFCWindow, $SFCCancelInsertDiscConfirm, 6)
        WinWaitClose($GenericSFCWindow, $SFCCancelInsertDiscConfirm)
        ConsoleWrite("4) Closed Cancel Insert Disc Window appeared" & @CRLF)
    EndIf
    Sleep(10)
WEnd
ConsoleWrite("5) WEnd Exit..." & @CRLF)

The first ConsoleWrite appears, then a while after the "Insert Disc" window pops up the loop exits, even though the main Window is still open ???!!!

Also, I've noticed that if I run the AU3Info tool and switch between focus between the "main sfc window" and the "insert disc" window, the Au3Info tool takes a long time to update. Without the "insert disc" window present, the updating of AU3Info is instantaneous.

And on my machine SFC is not consuming 100% of the CPU; in fact all processes (including SFC) run between 35% & 50%.

I think this must be something to do with SFC's behaviour: I'll try some other windows spy utilities and see if they have the same poblems as AU3Info.

Share this post


Link to post
Share on other sites

OK, this is definitely some strange SFC related behaviour!

Using Winspector (www.gipsysoft.com) info tool, it will sometimes tell me that the SFC windows, mostly the main one, are "not responding, probably hung".

Running variations of the loop that I posted, sometimes nothing will happen when the "insert disc" or "confirm cancel insert disc' window appear until I activate the main window.

Doing a little googling, it appears that other people who have tried automating SFC with other methods have run into similar inconsistent behaviour.

You might find an approach to a possible work around here: http://www.updatexp.com/scannow-sfc.html

basically by eliminating the reason for the "insert disc" window popup in the first place.

Good luck .

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

I thought it was an autoit bug but if other tools have issues reading informations from the SFC dialogs then most likely there's something weird in the SFC itself, maybe a broken message pump or a protection put to prevent setups from overwriting files that the SFC protects and closing the SFC dialogs to not let the user know. I tried running the script on the SYSTEM account, the same account where SFC (through winlogon.exe) shows the dialogs thinking it was a different user issue with no success so it really looks like it's an issue in the SFC itself.

Sadly I can't use the workaround you linked because I'm trying to make SFC work on nlited installs that lack the files SFC asks for (like legacy drivers for old hardware). I'll try to figure out how to write an application that launches SFC without the progress bar and closes all the retry dialogs finding them by the title and not by looking at their internal text, maybe that could work.

Thanks a lot for the help in figuring out where the issue was, I wouldn't have ever expected to be the SFC itself. muttley

Edited by TheGimp

Share this post


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
Sign in to follow this  
Followers 0