Sign in to follow this  
Followers 0
EdWilson

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

7 posts in this topic

#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.

Share this post


Link to post
Share on other sites



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.

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

EdWilson,

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

Like this: :blink:

#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


Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind._______My UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites

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

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