WinActivate is useless

[UnknownWarrior]

Is there some kind of Windows GUI that doesn't allow activation? Here is everything I have tried and have set:

- I have WinTitleMatch off (not exact)

- I've tried simply WinActivating the GUI -- worked 50% of the time

- I've tried WinMizimizeAll, sleep 5 seconds, WinActivate the GUI -- works 50% of the time

- I've tried all the above steps by setting all other windows WinSetOnTop to 0 (so no other window is OnTop) -- same results

What gives? :/ Is there any work around?

Edit: Forgot to add...

What's worse is that "If WinActivate($myTitle) Then" always passes true when the window is NOT ACTIVE. I need it visibly active for my MouseClicks to work (and no, ControlClicking will not work in my case).

Edited April 13, 2013 by UnknownWarrior

[PhoenixXL]

Try getting the WinHandle using WinGetHandle, and check if its the required handle [you can use au3info tool for this purpose].

Pass the hwnd instead of the title to WinActivate and check if it works

Edited April 13, 2013 by PhoenixXL

[JohnOne]

What app is the window from?

[Bowmore]

There is probable some other application you have running that is also trying to make sure that its window is the active one.

Try something like this

Local $hwnd = WinActivate($myTitle,"")
while not WinActive($hwnd)
        sleep(10)
        WinActivate($hwnd,"")
WEnd

or this

Local $hwnd = WinActivate($myTitle,"")
$hwnd = WinWaitActive($hwnd,"",10)
if $hwnd = 0 Then
        MsgBox(0,"Error","Unable to activate window" & @CRLF & $myTitle)
EndIf

[UnknownWarrior]

Try getting the WinHandle using WinGetHandle, and check if its the required handle [you can use au3info tool for this purpose].

Pass the hwnd instead of the title to WinActivate and check if it works

I'll try this, but seems like those would result in the same thing wouldn't they?

What app is the window from?

There's only one window it has displayed, and it's from a SEO program called GSA Search Engine Ranker.

Has a trial if you want to test it out.

http://search-engine-ranker.gsa-online.de/

Like I said, it works sometimes, and other times it doesn't. What I'm doing is automating this software to set up SEO projects for me (automatically). I run it on 6 VPS's and last night it all went haywire. One VPS has worked for almost 12 hours now, activating back and forth from GSA and another SEO software I automate as well.... but then when I try running it on the other 5 it REFUSES to show itself in the foreground so I can make the mouse clicks on it. What's worse is that I have a Do loop to WinActivate("GSA..." Until WinActive("GSA...") and it returns true for WinActive

There is probable some other application you have running that is also trying to make sure that its window is the active one.

Try something like this

Local $hwnd = WinActivate($myTitle,"")
while not WinActive($hwnd)
sleep(10)
WinActivate($hwnd,"")
WEnd

or this

Local $hwnd = WinActivate($myTitle,"")
$hwnd = WinWaitActive($hwnd,"",10)
if $hwnd = 0 Then
MsgBox(0,"Error","Unable to activate window" & @CRLF & $myTitle)
EndIf

Check reply above.

I do use a Do loop to check if it's active and it's returning true :/.

[SmOke_N]

3 things.

1. Why must the app window/gui be active? ( Use of Control* functions ( or even postmessage/sendmessage ) do not work? )

2. You set all the other WinSetOnTop to zero, did you set the window you're working with to one with WinSetOnTop?

3. You may be interesting at looking at the udf _WinAPI_SetWindowPos() and or _WinAPI_SetFocus() if it's absolutely necessary to have focus on that window.

[Bowmore]

Check reply above.

I do use a Do loop to check if it's active and it's returning true :/.

WinAcitvate() will always return a non zero value if the window exists and a message was sent to activate the window. It does not mean that the window is now the active window, it may take some time for it to become the active window. Thats why you need to check that the window has become active by using WinActive() or WinWaitActive() after using WinActive() and not just assume that it has become the active window. And if several windows are fighting for attention it can take a few tries to be successful. Why not post the relevant section of your code so we can better help you with why it only works some of the time for you.

[UnknownWarrior]

3 things.

1. Why must the app window/gui be active? ( Use of Control* functions ( or even postmessage/sendmessage ) do not work? )

2. You set all the other WinSetOnTop to zero, did you set the window you're working with to one with WinSetOnTop?

3. You may be interesting at looking at the udf _WinAPI_SetWindowPos() and or _WinAPI_SetFocus() if it's absolutely necessary to have focus on that window.

1. I've had a hard time wrapping my head around post/send message. I'd be more than willing to pay you to write some code to do it for this program with good comments (as if it's a tutorial so I can reproduce it then). The AUInfo doesn't return any control values on this GUI.

2. Yes I tried that, no success.

3. Thanks for a direction to look towards. I'll take a look at that and report my findings.

WinAcitvate() will always return a non zero value if the window exists and a message was sent to activate the window. It does not mean that the window is now the active window, it may take some time for it to become the active window. Thats why you need to check that the window has become active by using WinActive() or WinWaitActive() after using WinActive() and not just assume that it has become the active window. And if several windows are fighting for attention it can take a few tries to be successful. Why not post the relevant section of your code so we can better help you with why it only works some of the time for you.

You must have misread my comment to JohnOne. "Do loop to WinActivate("GSA..." Until WinActive("GSA...") and it returns true for WinActive" <-- WinActive checks to see if the given window is active. My apologies for not making it more clear, they're so very similar .

[SmOke_N]

1. I've had a hard time wrapping my head around post/send message. I'd be more than willing to pay you to write some code to do it for this program with good comments (as if it's a tutorial so I can reproduce it then). The AUInfo doesn't return any control values on this GUI.

I'm confused a bit. I downloaded the trial and I'm able to get control id's for everything but the trial popup ( which I was assuming was some kind of html anyway ).

Meaning that the Control* functions should work even if you have to use them with x and y client positions.

I'm not 100% but I think it's written in Delphi.

Might look around how others have automated Delphi items ( or verify first if it is in fact written in Delphi ).

[UnknownWarrior]

I'm confused a bit. I downloaded the trial and I'm able to get control id's for everything but the trial popup ( which I was assuming was some kind of html anyway ).

Meaning that the Control* functions should work even if you have to use them with x and y client positions.

I'm not 100% but I think it's written in Delphi.

Might look around how others have automated Delphi items ( or verify first if it is in fact written in Delphi ).

Thanks for looking into it. I now recall why I went with MouseClicks -- there was one control that I couldn't get (can't remember which one - had to do with a popup dialog I think), and it was the only one, but beings I had to deal with that regardless, I needed to activate the window anyways.

I guess the point here is still the fact that WinActivate (and WinActive for that matter) don't work as intended .

Edit: So I went and tested the WinAPI function you pointed me to and here are my findings:

_WinAPI_SetWindowPos($handle, $HWND_TOP, 10, 10, 993, 677, $SWP_SHOWWINDOW)

-- My flag states it should display the window (it didn't)

-- It did work, however I previously just tested with my original method (WinActivate) and that worked as well. Hence my problem again.... it only works 50% of the time with no way to debug it :/

So I don't know what to say... it's working now, but might not tomorrow.

Edit2: I just noticed something (it happened again on the same VPS with the Winapi_setwindowpos).

On Windows 7 (and Windows Server 2012 - what I use on my VPS's), when you click on a window in your taskbar it lights up the background of that window slightly more than the other non-activated windows. What happened when it failed is that it DID show GSA highlighted (as if it DID activate and it IS currently active), but as I sit staring at my screen GSA was still not active visually.

I tried doing WinMinimizeAll before and that didn't help (so it can't be an ALWAYS_ON_TOP flag on the other windows that would be causing this).

See the attached image below. The HelpFile window is the active window on my screen, which causes its lighter background in the taskbar.

Edited April 15, 2013 by UnknownWarrior

[SmOke_N]

It's not that these functions are failing or "not working" as intended.

It's that your application is not processing the messages in a timely manner or to your expectations.

This is no fault of the AutoIt/API code, as it's doing what it's supposed to do ( sending the message, and receiving the status ).

Like I said, you'll probably find more ways of manipulating properly ( I'd never use MouseClicks unless nothing else worked ) if you know what language you're dealing with.

On the popup you suggest, yes, that's the "About" popup I was referring to that wouldn't register anything but the class.

But, that in itself puts itself above all windows even if your app is minimized ( I saw this ).

One thing you could do is look up an old version of MouseClickPlus ( I think this it what it was called ).

This used postmessage api to send a mouse click message to the app as if it were it were the real mouse at an x and y position.

I believe it uses "client" coordinates, so you may want to check that.

You could get the handle of the popup probably from something like:

WinGetHandle("[CLASS:TForm]")

Where "TForm" is the the class of the popup window.

Pretty sure that window is all that stands in your way from not having to rely on faulty MouseClicks and hoping WinActivate produces the desired affect.

[UnknownWarrior]

It's not that these functions are failing or "not working" as intended.

It's that your application is not processing the messages in a timely manner or to your expectations.

This is no fault of the AutoIt/API code, as it's doing what it's supposed to do ( sending the message, and receiving the status ).

Like I said, you'll probably find more ways of manipulating properly ( I'd never use MouseClicks unless nothing else worked ) if you know what language you're dealing with.

On the popup you suggest, yes, that's the "About" popup I was referring to that wouldn't register anything but the class.

But, that in itself puts itself above all windows even if your app is minimized ( I saw this ).

One thing you could do is look up an old version of MouseClickPlus ( I think this it what it was called ).

This used postmessage api to send a mouse click message to the app as if it were it were the real mouse at an x and y position.

I believe it uses "client" coordinates, so you may want to check that.

You could get the handle of the popup probably from something like:

WinGetHandle("[CLASS:TForm]")

Where "TForm" is the the class of the popup window.

Pretty sure that window is all that stands in your way from not having to rely on faulty MouseClicks and hoping WinActivate produces the desired affect.

Yeah, I understand where you're coming from.

I want to thank you for the time you've put into this for me. I understand that your job as a moderator sometimes makes you question the legitimacy of some problems brought up by 'noobs' such as myself, but I'm glad you went ahead and checked out the issue regardless.

Keep up the good work here!