Wait Needed Before SetFocus>

[jalbt51]

I just posted a long question about a script I was getting error messages from, and after submitting it, the embarrassing realization hit me that I had neglected to set WIN_USEHANDLE=1. Problem solved. The only reason I'll leave this here is because it's such a neat device for waiting after executing a file till the window is ready to accept a SetFocus>. SUPPORT gave this to me- it never waits too long and it does wait long enough.

Let>WIN_USEHANDLE=1
GetActiveWindow>old_window,x,y
ExecuteFile>C:\Documents and Settings\Joel\Start Menu\1x1.bmp
Label>waitforchange_4
GetActiveWindow>window_handle,g,h
Wait>0.02
If>window_handle=old_window,waitforchange_4
Let>aa=window_handle
SetFocus>aa
WindowAction>1,aa

[fightcancer]

nice script!

I wonder if you could answer a question for me. several of my macros require a short wait (e.g. 0.05 s) AFTER I set focus on a window. why's that? so if I REM the "Wait>0.05" out after the SetFocus> command, then my macro(s) won't work.... is it due to the speed of the computer?

just curious,

[jalbt51]

You're not talking to an expert. However, it seems that bringing a window into focus is an event that takes time. The appearance of the window has to change(the title bar color and perhaps the window border must change). I wish I knew some sure signal that would allow a script to know "the window has come into focus and you don't have to wait any more". I've always simplified matters by working with a maximized window and absolute coordinates so I don't know if a getpixelcolor wait loop used with relative coordinates will help. (The problem is, the window is not up yet so you don't know where to look)

Does anyone know if it's possible to use relative coordinates to wait for a certain pixel color to appear in a certain place on the window no matter what size or position it comes up in? The instruction would have to be looking for a spot on a window that is not there yet. Wouldn't this produce an error message?

[JRS]

Jalbt51,

I do exactly what you describe with no problem. I "Hone in" on
pixel colors within a certain relative corrdinate range on the
screen with no problem at all. It's a very nice inherent
feature of Macro Scheduler.

Joel S.

[support]

I think that script must have been provided prior to the inclusion of the WaitWindowChanged function which now does the same thing. So you should just need the one WaitWindowChanged line rather than that loop.

[JRS]

Jalbt51,

Mjtnet Support is exactly correct for your purposes (and
I see mine as well in various instances in my scripts) to use WaitWindowChanged. Thank you support.

Joel S.

[JRL]

Support,

I'm confused. (this is a common occurance, ask my wife)

The help for WaitWindowChanged says:

This command causes Macro Scheduler to wait until the foreground window changes. If it doesn't change within the number of seconds specified in Timout, the command stops waiting and the variable WWC_RESULT is set to FALSE. WWC_RESULT is TRUE if the command terminated because the foreground window changed within the specified time. if Timeout is set to 0, the command will wait indefinitely.

I have never used this function since I have never had an instance of wanting to wait for something in my foreground window to change which from reading the help is what I thought this function accomplished.

Reading this post, makes me think that the function is actually waiting for a different window to come into the forground.

Could you please clarify?
Thanks,
Dick

[support]

It does the same thing. It waits for a change in foreground window. From one window to another. The latest help file is clearer.

[Bob Hansen]

And how is WaitReady>1 different?

[support]

Completely and utterly different! WaitReady waits for specific events to stop being processed by the current window. WaitWindowChanged waits until there is a change in foreground window ... i.e. a new or different window becomes the foreground window.