WaitForString doesn't always work

[ShawnVW]

I'm using WaitForString to detect a pop-up box on my screen. (Just to be clear: it's not a Windows dialog box, but part of the application I'm accessing through SecureCRT).

There are cases in which WaitForString simply does not detect these boxes. Here's an example:

    if .WaitForString ("COUNTRY CHANGE EXPLAINATION", 2) then
        .send "SAP - change 'USA' to 'US'"  & chr(13) & chr(13)
	[more code]
     else
	msgbox ("No Country Change found")
    end if

This snippet was working for a while -- it went to the IF clause when the box opened, but right now it is going to the ELSE clause.

(Yes, I know "Explanation" is misspelled; that how it is on screen. I copied and pasted it into my code.)

In some cases I can use Get() instead, but its not always easier.

Are there some rules or tricks about using WaitForString that I should know about? For instance, I've had trouble trying to detecting a string that was part of a line, instead of the whole line. If a caption said "ENTER NAME AND ADDRESS", then

 WaitForString("ENTER NAME AND ADDRESS")

would work more often than

WaitForString("ADDRESS")

[bgagnon]

Hi ShawnVW,

Do you have synchronous set to True in your script?

If not, that's the first thing that needs addressed. See more info in the scripting manual available on our website here. Specifically Section 4.2, the info titled Avoid "Missing" Data with Screen.Synchronous = True.

[ShawnVW]

Originally Posted by bgagnon

Do you have synchronous set to True in your script?

Yes, I do.

[bgagnon]

Hi ShawnVW,

Also, please be aware that WaitForString() cannot act on data that's already been echoed to SecureCRT. It has to be received while the script is running.

For instance, I've had trouble trying to detecting a string that was part of a line, instead of the whole line. If a caption said "ENTER NAME AND ADDRESS", then
Code:
WaitForString("ENTER NAME AND ADDRESS")would work more often than
Code:
WaitForString("ADDRESS")

The problem with using only a partial string is that if that text could *ever* conceivably be received at a time when you really do not want to act on it, you could get unintended results.

In other words, if this was received from the remote:

WHAT IS YOUR ADDRESS?
ENTER NAME AND ADDRESS

The latter WaitForString() above is *actually* triggered by the first line and not the second. Perhaps the best way to be certain of the data received from the remote (to be certain there are not non-printable characters that are altering the results) is to capture a raw log (File menu).

[ShawnVW]

That's good to know. I'll try it.

Thanks.