WinActive seems confused. bug? or perhaps I'm confused?

[EdWilson]

#NoTrayIcon

; Sets to search for a portion of the title of the window
AutoItSetOption("WinTitleMatchMode", 2)

;Intel PROSet/Wireless system tray icon has a similar name, but doesn't have the "connection utility" part at the end.
$TitleOfWindow = "Connection Utility" ;because WintitleMatchMode is set to 2 above, this doesn't have to be complete.
$ProgramToLaunch = "C:\Program Files\Common Files\Intel\WirelessCommon\iFrmewrk.exe"

;The next two lines of code are a workaround.  I DON'T want this message box.
;Without a box that comes up then is closed the previously active window is no longer active while the script is running.
MsgBox(0, "ProSet Button", "Minimizing, Restoring, or Starting" & @LF & "           as Appropriate", 1)
Sleep(50)
;without the sleep the WinActive portion of this script doesn't function at all.
;Even with the sleep it is intermittent.  Have tried sleep values up to 3000. 
;The 'Connection Utility' often stays inactive for the length of time of the sleep.
;i.e. it sometimes doesn't seem to become active until the autoit script finishes.
;UNLESS I click the ok button in the msgbox, in which case it always works correctly.

If WinActive($TitleOfWindow) Then
    ;MsgBox (64,"Active","Already active program per WinActive",2)
    WinSetState($TitleOfWindow, "", @SW_MINIMIZE)
    Exit
EndIf

If WinExists($TitleOfWindow) Then
    ;MsgBox (64,"it exists already","Already running per WinExist",2)
    WinActivate($TitleOfWindow)
    Exit

Else
    Run($ProgramToLaunch)
EndIf

I'm an AutoIt newb.

I'm having troubles with a script that will be executed when a physical button is pushed on a laptop and will:

1. Minimize a particular app if it is the active window at the time the AutoIt script is executed (this is the hangup)

or

2. Make it active & restored if it was minimized, (this part OK)

or

3. Launch it if not already running. (this part OK)

It seems that the previously active window greys out as soon as the autoit exe is executed.

Things I've tried:

- #NoTrayIcon

- @SW_HIDE on the autoit exe (both from within this script, and launching another script that acts on this one)

- having a message box come up then go away before looking for the active program. Some limited success with this. It intermittently works if the messagebox times out itself. It always works if I click on the ok button of that msgbox.

- I've tried sending an {Enter} to the msgbox, but this didn't work.

+Tried the enter both after a winwait active (but autoit doesn't appear at first glance to like reflexive commands.

+Tried the enter after a sleep of various lengths. no dice.

So, How does one get the WinActive() query to work as the first thing out of the gate?

Clues?? Any help would be greatly appreciated.

Ed

If it matters they are Panasonic CF-19s running XP Pro in which the push buttons are monitored via a HPLSKey.exe process that in turn launches the AutoIt exe file. For testing on a machine that doesn't have a button I imagine that you could launch from another script that has a delay (such that you could manually make the test program active, minimized, or stopped) then launches the equivalent of my attached script.

[omikron48]

Why not just use WinExists instead of WinActive for detecting that particular app then minimizing it regardless whether it's the active window or not.

[EdWilson]

Why not just use WinExists instead of WinActive for detecting that particular app then minimizing it regardless whether it's the active window or not.

The button should work as a toggle. If the program starts as minimized it should be restored. If it starts as active it should be minimized. (or if it's not running at all, it should be started.)

[omikron48]

If that's all you want, just use WinGetState to get the current state of the application window. You can just check the bit flags whether the window exists, is maximized or minimized, or active.

[EdWilson]

If that's all you want, just use WinGetState to get the current state of the application window. You can just check the bit flags whether the window exists, is maximized or minimized, or active.

Thanks Omikron. I did a WinGetState and the Window I want to examine came back inactive, even though it was active a fraction of a second before, when i pressed the button. So, that lead to the question of if, perhaps, the process that monitors that button was getting in the way. It was, and gave a 13, (active but not visible). This leads to the question of:

Any way to find out what the active window WAS just before running an AutoIt script?

[Melba23]

EdWilson,

Any way to find out what the active window WAS just before running an AutoIt script?

Like this:

#include <GUIConstantsEx.au3>

; Get current active window handle
$hActive = WinGetHandle("[ACTIVE]")

; Create and activate AutoIt GUI 
$hGUI = GUICreate("Test", 500, 500)
GUISetState()

; Pause a moment
Sleep(1000)

; Reactivate the previous window
WinActivate($hActive)

While 1
    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
    EndSwitch
WEnd

M23

[EdWilson]

Thanks Melba. It looks like that would get me the active window prior to launching the gui window, though not the active window prior to launching the script.

I've worked it out in an acceptable way.

For anyone else that runs into this...here was the deal.

Using a physical button on the front of a Panasonic Toughbook it made HPLSKey the 'active' but 'hidden' window, and launched my autoit script.

I didn't know how see what was the previously active window except by stopping the HPLSKey process. Minimizing HPLSKey with WinSetState for some reason didn't work.

If I applied a WinClose, it seemed to close but wouldn't respond afterward - the script would function properly on the first running but not subsequent ones. After a WinClose the process was still present in task manager though unresponsive to the button push.

If I incorporated a msgbox into the script that the user pushed, upon the disappearance of the msgbox the previously active window would come back and the script would be able to identify it and function the way I wanted. However I didn't want any mouse clicks (or anything other than pushing the physical button to be part of this.

What did work (not as elegant as I'd like, but completely functional) was to do a ProcessClose on HPLSKey.exe as the first item, then to Run it at the end of the script.

I did not experiment with trying to find the z-order in xp, if it's even accessible.

I didn't experiment with _WinAPI_ShowWindow ... @SW_Minimize either (just found it now while looking for the Z-order term)

Looks like _WinAPI_SetWindowPos ... $hAfter...$hwnd_bottom might do the trick as well, and be the 'elegant' solution I was looking for. May experiment when I have the time.

Ed