Does WaitReady need %0% or %1% ?

[jalbt51]

I THINK I've found a glitch in MS help.

Help Quote under WaitReady>paint_events

WaitReady suspends script execution until the foreground window has finished processing mouse, keyboard, show window, and optionally, paint events. Issue 1 to include paint events, and 0 to exclude paint events

an example is given

Run Program>"C:\Program Files\Microsoft Office\Office\WINWORD.EXE"
WaitWindowOpen>Microsoft Word*
WaitReady>0
Message>Word is now ready for input

I put a WaitReady> command into a script using paint thus:

SetFocus>1024x768 cntr pnt My Pctrs - Paint*
WaitReady>1

The program hung up at that point. After changing the command to Wait Ready>%1% it worked.

Perhaps the program was waiting for the 1 key to be pressed, as in WaitKeyDown> ??

Thanks so much for all the patient help from all of you. jalbt51

[Bob Hansen]

Did you check to make sure you do not have a trailing space after the "1" ?

Would be good to see more of the surrounding script. Can only guess at potentials without more details.

Some generic questions come to mind:
Is that "1024x768 cntr pnt My Pctrs - Paint*" an accurate WindowName?
What precedes the SetFocus line?
What follows the WaitReady?
Did you create and look at a log for the macro? Did it really fail on WaitReady?
Does it behave same way if you single step?

If you have not defined a variable of 1, then I think that %1% will be false, which may be the same as "0".

[support]

In your case WaitReady>%1% would be WaitReady>0 since 1 has not been defined as a variable. Hence why you got different results. The former is still waiting for paint events to happen (could wait forever depending on the app) and the latter wasn't, so it didn't 'hang' (you mean Wait - it didn't hang, it was waiting. That's what the command does).

[jalbt51]

Well, I changed WaitReady>%1% back to WaitReady>1 and, not only does the program(which works fine in the first case) hang up, but the taskbar icon is still flashing. (shift esc not only doesnt stop it but I lost my first version of this reply when I tried it.)

If WaitReady>%1% REALLY means WaitReady>0 then that version should not work, since this is all working with a Paint window- But
WaitReady>%1% is the version which DOES work.
I'll paste in the program that DOES work- the one that SHOULD be incorrect

When you press the eliminate trailing spaces button in the editor do you need to highlight the script first. I can't tell if I've done it right. Would it eliminate unwanted spaces in this case?

Is there a font which gives spaces as rectangles?

Thanks for patience...

1024x768 cntr pnt My Pctrs.bmp is a blank Paint window sized to 1024x768
Set your Mouse properties, pointer options, pointer speed to the fifth line from the left. This will cause the pointer to move one pixel per each press of the numberpad's arrow(accessability control)

Let>WW_TIMEOUT=5
CapsOff
//Before running this program, copy a rectangular bitmap image from a photo editor onto the clipboard.

//Open and Maximize My Pictures
ExecuteFile>C:\My Documents\0000 My Pictures\1024x768 cntr pnt My Pctrs.bmp
WaitWindowOpen>1024x768 cntr pnt My Pctrs - Paint*
WaitReady>%1%
WindowAction>1,1024x768 cntr pnt My Pctrs - Paint*
WaitReady>%1%
//window here means the center panel Paint uses to manipulate images- not surrounding control panel etc.

//Initialize values for pixel above-left of window's centerpoint
Let>x=573
Let>y=426
//These values mark the upper left coordinates
//of the four pixel square, the center point of which
//is the center point of the window

//Provide new x,y values for cursor movements
Let>x1=x+1
Let>y1=y+1

//(in the whole screen coordinate system 62,43 is the extreme upper left pixel.
// Therefore 511,383 translates to (511+62,383+43) or(573,426).
////(it is not 512,384 because the window's relative upper left coordinate is 0,0
////Therefore A,B refers to a coordinate. AxB refers to size in pixels.
////Thus, the extreme upper left pixel is size 1x1 at coordinate 0,0).

//Paste already copied bitmap into window(now floating).
Press CTRL
Send>v
Wait>0.07
Release CTRL

//Move Mouse to exreme upper left corner of window (relative move 0,0)
MouseMove>62,43
Wait>0.07

//Grab pasted bitmap and move it to pixel positioned above-left of the window's centerpoint
LDown
MouseMove>x,y
Wait>0.07
LUp
Wait>0.07

//Freeze pasted bitmap into whole window by selecting all.
Press ALT
Send>e,a
Wait>0.07
Release ALT
Wait>0.07

//Nail down the floating bitmap and leave a copy of it floating above it
Press CTRL
Wait>0.07
LDown
Wait>0.07
LUp
Release CTRL
Wait>0.07

//Choose to make white background transparent
MouseMove>30,300
Wait>0.07
LClick
Wait>0.07

//Bring up Flip and Rotate Box.
//This automatically chooses Flip horizontal(flipping bitmap around a verticle axis).
Press CTRL
Send>r
Wait>0.07
Release CTRL
Wait>0.07

//This performs the Flip horizontal.
PushButton>Flip and Rotate*,OK
Wait>0.07
//The floating image now overlaps the original by two pixels


//Move Mouse to upper right-position of the floating image.
MouseMove>x1,y
Wait>0.07
//The cursor is now positioned at the upper-right corner of the flipped bitmap's, now floating, copy.
////The bitmap flips horizontally around it's vertical center line (The exact center of the window is a line.)
////If the exact center of the window were a pixel, then x here would not change.
////(This would only happen if the window was an odd number of pixels long.)).

//Grab the floating copy and move it one pixel to the left, so that
//it overlaps the original bitmap by only one pixel.
LDown
Wait>0.07
MouseMove>x,y
Wait>0.07
LUp
Wait>0.07
////Each pixel on the edge "floater", which overlaps the original on a horizontal row, is now positioned
////over the corresponding pixel of the original under it.

//Freeze floating bitmap into whole window by selecting all
//so that the whole window's bitmap is floating, but with nothing underneath.
Press ALT
Send>e,a
Wait>0.07
Release ALT
Wait>0.07
//The image is now a combination of two

//Nail down the floating bitmap and leave a copy of it floating above it
Press CTRL
Wait>0.07
LDown
Wait>0.07
LUp
Wait>0.07

//Bring up Flip and Rotate Box
Send>r
Wait>0.07

//Choose verticle flip
Press Down
Wait>0.07
Release CTRL
Wait>0.07

//This performs the verterticle flip
PushButton>Flip and Rotate*,OK
Wait>0.07

//Change cursor position values from x,y to x,y1. This is the pixel positioned below-left of the window's centerpoint.
//This is now the exact bottom-center of the fliped floating rectangle.
//////odd plus odd minus one, equals odd
//////even plus even minus one, equals odd
////The bitmap flips vertically(around a horizontal axis) around the center line
MouseMove>x,y1
Wait>0.07

//Grab floating image and drag it up one pixel so that
//it overlaps the original bitmap by only one pixel.
LDown
Wait>0.07
MouseMove>x,y
Wait>0.07
LUp
Wait>0.07
////Each pixel on the edge "floater", which overlaps the original on a vertical row, is now positioned
////over the corresponding pixel of the original under it.

//Freeze bitmap into whole window by selecting all
Press ALT
Send>e,a
Wait>0.07
Release ALT
Wait>0.07
Press Shift
Press Esc
Release Shift

[jalbt51]

Line numbers 8 and ten are the relavent ones. Can I make line numbers visible when I paste script in?
Thanks again jalbt51

[jalbt51]

When trying to debug this program to see what MS says about %1%, the debugger passes over lines 8 and 10 without blinking. After line 9, the maximized Paint window appears at each step and is hidden again. But when it hits line 30 (Send>v) the Paint window doesn't appear and F8 won't do anything more. All I can do then is to stop the debug. The Refocus Windows box is checked. ??
Thanks again. jalbt51

[support]

Hi,

Since 1 is not defined as a variable in your script, WaitReady>%1% will probably cause WaitReady to act in default mode which is WaitReady>0. So it will not wait for paints events.

As for why WaitReady>1 gives you the impression it has hung up - it is WAITING for the active application to finish processing windows paint messages. Trouble is the particular application in question may never finish processing paint events. Perhaps WaitReady>1 is not going to work for you in this instance. Perhaps the application is constantly being refreshed or doing some painting.

And your observation that WaitReady>%1% DOES work is correct - because this is the same as WaitReady>0 which does NOT wait for paint events and therefore there is no apparant hang.

First of all you are confusing variables with literals. %something% means use variable something. So %1% means use variable 1. That doesn't exist. WaitReady>1 waits for paint messages, WaitReady>anythingelse doesn't. So WaitReady>FRED or WaitReady>0 or WaitReady>%1% or WaitReady>%2% will WAIT for paint events.

Secondly the script is waiting - in a loop, for messages to complete. I don't call this hanging. But either way it is waiting indefinitely because it has been told to.

Clearly WaitReady is not useful for this particular script/application.

When you press the eliminate trailing spaces button in the editor do you need to highlight the script first. I can't tell if I've done it right. Would it eliminate unwanted spaces in this case?

You do not need to highlight the script - it eliminates all trailing spaces in the entire script. It shouldn't be necessary - I don't believe your 'problem' here has anything to do with trailing spaces. Copying from HTML (a web page) can sometimes add control chars to the end of lines. But Macro Scheduler removes these during pasting, so shouldn't be a problem. If in doubt you can remove trailing spaces with this option.

[armsys]

Hi Support,

So WaitReady>FRED or WaitReady>0 or WaitReady>%1% or WaitReady>%2% will WAIT for paint events.

should read:

So WaitReady>FRED or WaitReady>0 or WaitReady>%1% or WaitReady>%2% will NOT WAIT for paint events.

Please correct me if I'm wrong. Thanks.

Happy scripting.

[support]

Sorry, yes, you are correct.

Unless of course FRED, 1 or 2 are declared variables set to a value of 1.

[jalbt51]

All right, now I think I've got it.

WaitReady> waits for the command AFTER it to be ready to be executed,
and WaitWindowOpen> waits for the command BEFORE it (ExecuteFile>) to finish?
Please tell me if this is correct. I won't get far if I get things wrong now.

I was writing this as if WaitReady> would hold things up long enough for the event BEFORE to finish.

Thanks muchly for all the help, jalbt51

[armsys]

Based on my scripting experiences of innumerous failures, I would point my finger to WaitWindowOpen>.

Nonetheless, Support already detailed all possible scenarios which would cause an infinite wait.

Suggested modified script:
//Open and Maximize My Pictures. C:\My Documents\0000 My Pictures\1024x768 cntr pnt My Pctrs.bmp
Wait>5
WaitWindowOpen>Paint*
WaitReady>0
WindowAction>1,Paint*
Wait>1
Msg>Hello, I"m Okay
Goto>End
.
.
.
// Your last statement in your script
Label>End

BTW, please ensure all invisible trailing SPACES are eliminated.
Please keep us posted about the outcome.

Happy scripting. Have a nice weekend.

[jalbt51]

Wait a minute- doesn't WaitReady>0 refer to NON paint events?

Is the opening of ANY window a non-Paint event, even if it's a Paint window??!?

Does WaitReady> wait for the command AFTER it to be ready?

The reason I tried WaitReady> instead of Wait> is that I was hoping to make the run a bit faster. (Wait> works but sometimes fails: if the window being opened is being opened for the first time since rebooting, or if there is so much else open that the sytem can't get the window up fast enough.)(Setting the Wait> to 5 seconds works, but I'm trying to get this fast and smooth)

This business of waiting, with Paint, is a constant hassle. I always have to guess where to put a wait, and how long to make it

OK, I've eliminated the WaitReady's and it works anyway. If it failed with WaitReady>1 (1 refering to Paint events), then as support and others have implied, WaitReady%1%> allowed the program to work because IT wasn't "working"(wasn't waiting for any Paint events).

Reinserting WaitReady> into this program, causes infinite waiting AFTER itself. Insertion in line 8 alone AFTER WaitWindowOpen>1024x768 cntr pnt My Pctrs - Paint*), allows opening of the not yet maximized window. Insertion in line 10 alone allows window maximization, before infinite wait hits.
But what WAS WaitReady>1 waiting for?? Why wasn't line 9 WindowAction>1,1024x768 cntr pnt My Pctrs - Paint* good enough for it? Or what about further on at line 29 Press CTRL ??

Thanks for putting up with all this hassle. jalbt51

[armsys]

Hi jalbt51,

Thanks for your reply.

WaitReady>0 means to wait for an active/focused window until it's ready to accept keyboard/mouse input, even though the window has not yet finished displaying the whole screen such as toolbars, a table and a picture. Painting is the term used in the document. It might cause confusion to some people. WaitReady>1 will stop "waiting" only after the window stops displaying or changing the screen.

In case of WaitReady>%1%, because 1 was never declared or defined, it's identical to WaitReady>0.

In case of WaitReady>1 in your described situation, the infinite wait scenario theorized by Support is highly likely. In your situation, I would use combined statements of WaitReady>0 and Wait>n to optimize between speed and reliability.

I occasionally encounter infinite wait caused by WaitWindowOpen>, but never with WaitReady>0 or WaitReady>1.

Happy scripting.

[Bob Hansen]

The reference to "Paint" in the WaitReady command does not refer to the "Paint" program. It refers to the OS "painting" the screen images to the monitor, or doing a refresh to a window for some reason.

The time to Wait in WaitReady is determined by many factors, but provides control so that you will not try to do things before the refresh processes have been completed. Using Wait alone, may be too short to allow refresh but may be quicker for time. You may not need to wait for the windows to be fully painted before you continue your script. That will be up to you.

Some of this may be trial and error. I believe that I have even used a combination of WaitReady>1 followed by a Wait>2. But I have always been willing to give up the speed for the quality control of the results.