waitfor "text" not recognizing text

My first guess would be that some non-printable character of some sort is sent with the string and since Procomm is looking for the exact string you specified (not how it appears), that would throw off the waitfor command. You can use Procomm's Monitor Window to see just what is being sent and adjust your string if necessary. I've copied some information on the Monitor Window from my site below:

Procomm's Monitor Window can be used to view the incoming and outgoing data, in both hex and ASCII format. To activate this window, select the Data | Monitor Window menu item. Resize the Monitor Window so that you can view the entire width of the window, then click back in the Procomm Plus window so that the Monitor Window does not have focus. Incoming text is displayed in red, while text you send is colored blue. The Monitor Window can be handy for viewing incoming escape sequences (to determine if Procomm Plus is responding properly to them) or to verify that the program is sending the data you think it should be.

Well, I was able to monitor the information going out and coming in. Nothing unusual, no odd hex values, simply the text followed by a carriage return and line feed. Same thing as what I saw in the capture file.

Any other ideas?

Have you tried with a shorter string in the waitfor-command?
maby:
or something similar?
That is, use a shortest possible string that would
uniqly match what your looking for.

Can you take a screenshot of the Monitor Window and post it here (I think that is possible)?

Okay, I've got a screen capture of the last portion of the monitor window.

You'll see that at the end of the script, I actually do send the logoff command. That's because I've had to remove the "FOREVER" timeout value from my script. It simply waits then sends the text to the screen. This works fine for quick response times, but when I've got slow response times or I'm receiving an extremely large file, it doesn't work so well.

OK, no bogus or non-printable characters present in the screenshot. Can you post some of your script prior to the waitfor command to see if there is an issue before that command?

I'll do even better.
The entire script can be found at PasteBin.

The line in question is [highlight]highlighted in yellow[/highlight].

Does it seem like the script is running as expected prior to the waitfor and isn't getting hung up anywhere or skipping sections of code? One thing I noticed is that the file transfer just prior to the waitfor command doesn't use the way I "like" to use, so you might try the following code to replace your existing if $xferstatus loop to see if it works a bit better:

iStatus = $XFERSTATUS
while iStatus == 1
iStatus = $XFERSTATUS
endwhile
if iStatus == 2
;Transfer successful, continue with script execution
elseif iStatus == 3
;Transfer failed, perform error handling
endif

The code doesn't appear to be skipping around at all. The transfer "above" the section in question goes just fine.

I saw that was your preferred way, from your code samples.

I forget why I wasn't using that... seems I had seen something somewhere that said $XFERSTATUS wasn't being updated correctly in WinXP.

I'll wrap my code around that to see what difference it makes.

Thanks for keeping with me on this!

Hmm... while adding my code I *DID* spot something that makes me go like this...




From my PasteBin post, line 352 has a waitfor cmd. Then, if they only upload files (iRecvFiles is 0), the script hits another waitfor prompt at line 390. If you have a waitfor followed by the exact same waitfor line... it'll stick there, won't it?

They (my clients) are telling me it's locking up after receiving files, but I wonder if they are only sending files...

The script won't stick per se. However, if you have two waitfor commands looking for the same string and the string is only received (and handled) by the first waitfor, the second waitfor will timeout and execute any error detection and correction code you may have put in. However, it doesn't look like this is the case with the waitfor on line 390 since it isn't of the "if waitfor" format and you're not checking for success/failure after the waitfor command.