detection of end of process

[Paul]

I'm pretty new with Macro Scheduler and I tried to create a macro today that starts a process. At the end of the process a pop-dialog appears with request for conformation. I am not able to detect the moment when this dialog box pops up. However, I need to because it asks for a conformation (ENTER).
Both the process window and the pop-up window have the same title, I have tried to search for the word 'successfully' in the pop-up window, tried to compare the x position of the active window for both windows, but nothing seems to work. Does anyone has another suggestion I can use?

Thanks, Paul

[Ernest]

Hi Paul,
an option (sometimes the last), is the WaitPixelColor>command. Identify a unique Pixel on that PopUp (use the Editor/FollowCursor/PixelColor). The command will force the script to wait till the Pixel at that coordinate changes the color (e.g. when the PopUp appears ).

Code: Select all

WPC>WaitPixelColor>0,652,355,0

Press Enter

This checks the pixel at coordinate 652,355 to become "black".
If will wait indefinitely (see the command reference) for that change.

Rgds
Ernest

[FQ]

Do not you think that the use of WaitPixelColor> is a shoddy thing to do?
I think that the MacroScheduler may have an instruction that stop the macro till the task is done (appear pop-up and so on). Something like WaitIdle>
The need of using WaitPixelColor> is a bad solution.

[Marcus Tettmar]

Hi,

No solution is "shoddy". Automating windows applications via the user interface because they don't offer any other way to automate them is all about workarounds.

Some other possible solutions:

1. Use the WaitWindowChanged function.

2. Use a loop with GetActiveWindow waiting for the X,Y coords of the active window to change.

3. Use WaitReady>1 - this may work for your app.

Hope this helps,
Marcus

[FQ]

What is WaitWindowChanged?
How does it works?
When to use it?

[Ernest]

Hi,
MSched is not to blame. WPC> is an option which you can use to check for a change on the screen , e.g. if you're not able to detect an unknown window/popups name with GetWindowTitle> , which lies in the window/popup developer's responsibility (believe me there's a bunch of developers around who don't care about users/usability ).

It has to be defined a condition under which the script can go on.
Therefore it's not important if it's the change of a pixel color on the screen or the appearance of a window (title).

Ernest

[FQ]

Well, I think the MacroScheduler need a command like WaitIdle>.
The solution of using WaiPixelChaged> is boring. You have to look for a pixel that changes, see its position and color and so on. And maybe there is not a changing pixel or you do not find.

The good solution is a new instruction like WaitIdle>.

[Marcus Tettmar]

Hi,

Try the WaitReady command.

[FQ]

Well, I tried with the WaitReady command and it does not work fine.
I had to use the WaitPixelColor. Another users do the same.
Well, I think the WaitPixelColor is, by now, the only solution. But it is not a good solution.

Macro Scheduler needs a better WaitReady command or a WaitIdle command. (Or maybe a variable like RP_TASKDONE).

[Ernest]

Hi Marcus,
here how it's used with AutoIt.

RunWait, [, [,]]

Same as the Run command but waits for the program to finish before continuing (recommended when running DOS commands such as copy, md, del, etc.).

This command will also set the variable %ERRORLEVEL% to the return code of the program.

Copyright: Jonathan Bennett

Rgds,
E.

[Marcus Tettmar]

Hi,

Here's how you do the same thing in Macro Scheduler:

Let>RP_WAIT=1
Run>program path and name

And get the return code in the %RP_RESULT% variable.

If you need to set the working directory issue Change Directory before hand.

** However, this is off topic and isn't the solution to the topic here. The original poster wanted to know some ways of detecting the end of an event within a program execution.

The answer to this varies and, unfortunately, there is no magical answer, command or variable that can be used. Common solutions are:

1. Using WaitWindowOpen when waiting for windows to appear - often associated with an event completing if a window appears at the end of it, such as a dialog box.

2. WaitWindowChanged can be used for the same thing without having to know what the new window is - just that the active window changed.

3. WaitPixelColor is useful for watching for status bars, for example, or a change on the screen when there is no other clear cut solution, such as a window appearing.

4. WaitCursorChanged when the cursor changes appearance.

5. WaitReady to wait until there are no more keyboard, mouse and windows paint events being processed. But Windows uses zillions of different messages and some apps may be processing messages that we don't know about. In short there is no magical catch all solution.

These are just a few. There are many ways depending on the application, the type of event etc etc. Loops that check the clipboard for clipboard processes, or IfFileChanged, IfFIleExists, or loops that look at the file size for processes that create files ... the list is almost endless.

I know the original poster feels strongly that WaitPixelColor is not a nice solution. Well, sometimes it is the only solution. And since we are concerned with simulating user activity and since the user looks at the screen to make his mind up whether to continue or not, is not looking at the color of some part of the screen analagous and as close as you will get to simulating user decisions? If the end result of a process is a change on the screen, then why not look for that?

Having said that I have never had to use this approach myself. I have used all the others I have described, but so far been lucky enough to have automated processes that could be automated without looking at the pixel colour.

[SUG]

Well, Marcus, you are right.

Sometimes, we need to detect the end of a event within a program execution. RP_WAIT does not work for this.

Indeed, there is not a magical answer, command or variable to be used. But I would like there would be.
And I do not like that Macro Scheduler simulate the activity of a user. I like the macro run fast as posible. I want the macro waits if it has to wait but only if it is needed. What can be done? WaitPixelColor is many times a bad solution but the only solution.

Well, MacroScheduler need a variable like RP_TASKDONE that make the macro to wait till the end of a event within a program execution. Of course, it would be different from RP_WAIT.

[Marcus Tettmar]

Well, MacroScheduler need a variable like RP_TASKDONE that make the macro to wait till the end of a event within a program execution. Of course, it would be different from RP_WAIT.

If only this were possible!

[Guest]

Indeed, there is not a magical answer, command or variable to be used. But I would like there would be.(

Please send an email to [email protected]

And I do not like that Macro Scheduler simulate the activity of a user. I like the macro run fast as posible. I want the macro waits if it has to wait but only if it is needed.

Keh? You are, by default, automating a manual process, therefore you MUST simulate the process.

The only other way to do it is to write a program yourself, rather than driving one someone else has written.

Also, by removing checking for things like WWO's etc, you run the risk of your script not working on anything other than your current machine. Get a new machine, or compile your script into an EXE for others, and you could get different and unpredictable results.

To get the same results as a user driving an application, you have to do what they would do. That requires jumping through all the hoops of making sure the right window is focused, waiting for things to happen etc.

Well, MacroScheduler need a variable like RP_TASKDONE that make the macro to wait till the end of a event within a program execution.(

No it doesn't. No such thing can realistically be done. IMHO of course
[/b]