Test for Window Responsiveness

[wth]

Hi There,

I'm writing a script for a java program and at one part I have to wait for it to scan some items. I'm using Not Winexist() to wait for the window to disappear. This is working correctly. The issue that I'm having is that the main screen it returns to is now active but not responding so WinWaitActive doesn't work. Unfortunately the not responding can be from 7 seconds to 7 minutes.

Is there anything I can do to check for window responsiveness or will I be stuff with a 10 minute sleep to buy it plenty of time to respond?

[Melba23]

wth,

Welcome to the AutoIt forum.

Is there anything about this window (title, colouring of a control or area, etc) that indicates when it is ready to go again?

M23

[wth]

  On 10/6/2010 at 12:55 PM, 'Melba23 said:

wth,

Welcome to the AutoIt forum.

Is there anything about this window (title, colouring of a control or area, etc) that indicates when it is ready to go again?

M23

The titling no but I could probably use pixel color of something. I had to do that at another point in the macro, didn't think to try it here. The window goes completely blank when unresponsive so I'll find a point when it's good and test. I'll let you know if it works.

Thanks!

[Ascend4nt]

Perhaps try using the API call 'IsHungAppWindow' in a loop to wait until it reports the window as not 'hung'?

[wth]

  On 10/6/2010 at 1:00 PM, 'wth said:

The titling no but I could probably use pixel color of something. I had to do that at another point in the macro, didn't think to try it here. The window goes completely blank when unresponsive so I'll find a point when it's good and test. I'll let you know if it works.

Thanks!

Hi, this worked perfectly. Thanks!

I'll take a look at IsHungAppWindow because that would probably be a cleaner solution if it works.

[wth]

  On 10/6/2010 at 3:10 PM, 'Ascend4nt said:

Perhaps try using the API call 'IsHungAppWindow' in a loop to wait until it reports the window as not 'hung'?

Hi, just to make sure that I wrote this correctly. I added...

Dim $hWin

$hWin = WinGetHandle("name")
While dllCall("User32.dll", "BOOLEAN", "IsHungAppWindow", "HINSTANCE", $hWin)
    Sleep(1)
Wend

This didn't work but it doesn't mean that it's written correctly. I don't know how to force a window to be unresponsive so it's a bit difficult to test.

[Ascend4nt]

That's not how you check the value of an API return. Any DLLCall() that succeed will return an array, otherwise it will return something like ''.

What you want is something like this:

While 1
    $aRet=DLLCall('user32.dll',"bool","IsHungAppWindow","hwnd",$hWnd)
    If @error Or $aRet[0]=0 Then ExitLoop
WEnd
; If @error Then... (if the DLLCall failed, you should probably try another method)

As far as forcing a window to be unresponsive.. well, it can't really be done with a 'Suspend' command, or any other simple command, really (unless you force it to crash maybe). Since you were getting a window that was being unresponsive in the first place, thats why I chimed in with that API call (which returns non-zero in $aRet[0] if a window doesn't look for or respond to any Window messages within a given amount of time). If you no longer have the problem, then no need to use the call.

[wakillon]

Take a look at _WinAPI_IsHungAppWindow() of WinAPIEx.au3 !

[Ascend4nt]

Right, because it makes so much more sense to use a gigantic UDF for one API call.

[wakillon]

Sorry you're right !

Hey guys stop using udfs, it's so gigantic !

[Melba23]

Ascend4nt,

  Quote

it makes so much more sense to use a gigantic UDF for one API call.

I share your sentiments absolutely and try to avoid using #include files in my UDFs for this very reason.

But it is worth remembering that if you use Obfuscator with the /STRIPONLY parameter it removes all the unused functions (and constants) when you compile. So you just get the sections you need from any massive (but very handy) #include files.

I would recommend this approach to those who are not very confident about coding DLL calls directly.

M23

[Ascend4nt]

This is bordering on moronic. The API call was provided, as well as the method to call it. Why waste your breath telling someone to use another UDF when the answer is here in the thread.

Melba, I'm well aware of the /striponly Obfuscator parameter, as well as others that are useful in shrinking UDF's down. I'm also aware of the usefulness of some UDF's to newbies.

However, the answer was provided, and wakillon decided to ignore it and suggest someone go look at the WinAPIEx UDF for the same exact thing, only in a gigantic package. In what world does that make sense.

[Melba23]

Ascend4nt,

  Quote

This is bordering on moronic

My comments above were not intended to cause you personal offence and my apologies if any was caused. There are differing views expressed in this topic - that makes none of the contributing members borderline moronic.

You and I are happy using DllCall, but many other coders take one look at the syntax and immediately the "Too Difficult" light comes on - I freely admit that my "Caution" light starts flashing brightly. Suggesting the use of a UDF function from an #include file gives these coders access to the functionality but puts them at a nice safe distance from the "dirty" syntax - which is why the UDFs like WinAPIEx were written in the first place (thanks Yashied!).

And I was absolutely sure that you would be aware of the "slimming" properites of Obfuscator - the comment was aimed at any newer coders reading who might have thought that using a largish UDF for a single function was not a good idea when it is extremely simple to remove the unwanted functions when compiling.

Let us hope that the OP manages to get what he wants - whichever of the methods he uses. Have a nice weekend.

M23

[Ascend4nt]

Melba, my apologies for my remarks.. really I was directing the 'borderline moronic' comment towards wakillon's post. And honestly, I usually try not to say things like that but this whole discussion over a few lines of code is overkill. I gave the necessary code and calling syntax, nothing more was needed other than a copy-and-paste.

However, as you said - its up to 'wth' what they choose to do or use.

And don't worry, your words aren't lost on me. You seem like a pleasant enough person with good intentions. And the main point is to help others, so whatever productive advice you put out there is all good.

take it easy

[wakillon]

  On 10/9/2010 at 8:32 AM, 'Ascend4nt said:

Melba, my apologies for my remarks.. really I was directing the 'borderline moronic' comment towards wakillon's post. And honestly, I usually try not to say things like that but this whole discussion over a few lines of code is overkill. I gave the necessary code and calling syntax, nothing more was needed other than a copy-and-paste.

However, as you said - its up to 'wth' what they choose to do or use.

And don't worry, your words aren't lost on me. You seem like a pleasant enough person with good intentions. And the main point is to help others, so whatever productive advice you put out there is all good.

take it easy

my dear ascend4nt

How can I say this politely?

It makes no sense is to answer to someone who says to someone else to take a look to an existing function, that is moronic !

It makes no sense because my first intention was to Confirm your solution by indicate a Yashield Udf like a great reference !

It makes no sense because to talk about udf size, like if some kb were important in the functioning of a script !

It makes no sense on this nice forum to be rude and contemptuous for impose his opinion !

wakillon.

Thank you, Melba for your diplomacy !

Edited October 9, 2010 by wakillon