Waitfor not "firing"

[ianb16]

Hi,

I have a problem with waitfor not firing with a system I am dialing into.

My settings are a VT-220 terminal 8-N-1 and stripping the 8th bit.

I have tried both STRIP and RAW, and escape characters and no escape charaters in the waitfor.

Here is the prompt I am looking for with and without escape characters:

waitfor "mUN,^[[1mS^[[mAVE,^[[1mD^[[mELETE,^[[1mE^[[mXIT,^[[1mV^[[mIEW,^[[1mC^[[mOPIES,^[[1m?^[[m)^[[K"

waitfor "RUN,SAVE,DELETE,EXIT,VIEW,COPIES,?)"

Question 1)
Any suggestions?

Question 2)
Does the entire waitfor string have to match the entire string received in the buffer to fire?
For example, if the screen displays "Press any key to continue..." and you have a statement WAITFOR "Press any".

Thanks.

 

[udainius]

It does not have to match the entire string.

I also had a problem with the waitfor but it seemed to be bypassed. I placed a (pause 1) command just before the waitfor command and it has worked every time. It seems like it continues with processing before it has established that it needs to wait and that pause gave it the time to relize that it has to stop to look for something.

 

[knob]

I would try having your waitfor command look for just part of the string. You will need to include the escape sequences as part of that string, otherwise the text-only string in your waitfor command will never be "seen" by the script. I would recommend trying to make the string you are waiting for as small as possible, such as D^[[mELETE, as long as that particularly string is never sent at any other time by the remote system. I wouldn't use the RAW or STRIP flags with the waitfor command.
aspect@aspectscripting.com

http://www.aspectscripting.com

 

[ianb16]

Thanks for the replies but neither suggestion would work.

I have recorded the sessions to ensure that I was waiting for the proper characters.

Is it possible that there are hidden characters? or that the characters are not what they seem to be?

 

[hankm3]

Hello,

If you Captured the Session, I would Open it up with a HEX Viewer and Look at the Characters to see if there are any Hidden. You can download a Free Hex Viewer off the Web.

Hank

 

[knob]

If you recorded the characters with Procomm's Script Recorder, then the strings should be 100% identical. One possibility is that the escape sequences have changed since you recorded the script, or that the escape sequences may vary (I'm not sure if those are color codes off the top of my head or not). I would double check this by using Procomm's Monitor Window to compare what is being sent now to what was originally recorded. 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. On the left side of the window will be the data in hex format, while the corresponding ASCII characters are on the right.
aspect@aspectscripting.com

http://www.aspectscripting.com

 

[ianb16]

I have noticed that what was recorded in the recorder script as "^[[" shows up as "left arrow and [" (hex 1B 5B) in the monitor window.

Does this give you any clues?

 

[knob]

That is OK. ^[ is an escape character and the left arrow is the graphical representation of an escape. aspect@aspectscripting.com

http://www.aspectscripting.com

 

[ianb16]

Just to elaborate a bit more, I will show what is displayed on the screen versus recorded versus the monitor.cap.

On the Screen:

ENTER COMMAND (1,2,3,4,5,6,RUN,SAVE,DELETE,EXIT,VIEW,COPIES,?)

where this all appears on one line and where 1, 2, 3, 4,
5, 6, R, S, D, E, V, C and ? are "bolded".

Recorded:

waitfor "[mUN,^[[1mS^[[mAVE,^[[1mD^[[mELETE,^[[1mE^
[[mXIT,^[[1mV^[[mIEW,^[[1mC^[[mOPIES,^[[1m?^[[m)^[["

Monitored: where I will put ESC instead of left arrow.

ESC[mESC[?25hESC[23;1HENTER COMMAND (ESC[1m1ESC[m,ESC[1m2ESC[m,ESC[1m3ESC[m,ESC[1m4ESC[m,ESC[1m5ESC[m,ESC[1m6ESC[m,ESC[1mRESC[mUN,ESC[1mSESC[mAVE,ESC[1mDESC[mELETE,ESC[1mEESC[mXIT,ESC[1mVESC[mIEW,ESC[1mCESC[mOPIES,ESC[1m?ESC[m)ESC[K

Does this give anyone a better clue to this problem?

 

[knob]

I noticed in the recorded string, there options 2 through 6 are not in the string. Do the numeric options in this string vary, or did the record operation not get all of the data?
aspect@aspectscripting.com

http://www.aspectscripting.com

 

[ianb16]

That is correct. The recorded string only starts after the escape sequences before the "R".

Is there a limit to the number of characters in a waitfor? or in the recording "conversion" to a waitfor? I counted approx. 94 characters in the recorded waitfor.

 

[hankm3]

Hello,

The Help File states 256 Characters in a Waitfor.

 

[knob]

The only limit I think would apply is the 255-byte limit on a string's length in ASPECT, so that shouldn't be the problem.

I looks like you may have found a bug if the recorded string doesn't match what appears on screen. If so, you should be able to manually create a waitfor string that will match the incoming string, as long as it never varies in anyway.
aspect@aspectscripting.com

http://www.aspectscripting.com

 

[ianb16]

The system I am dialing into is an ADP Auto Dealer System.

I am not sure if it is a bug or the way the sytem paints the screen. For example the monitor recording of:

mESC[?25hESC[23;

May position the cursor at the 25th position and 23 rd line.

If so, then the recording would only pick up the display at that point.

Anyways, I appreciate all your assistance. I am still working through it. If you have any more idea's please let me know.

 

[ianb16]

Just to finish off...

I found if I used a string of letters that is not interrupted by escape characters the waitfor was successful.

In this case I used:

waitfor "OPIES"

Thanks for your assistance in the last few days.

Ian