when - target - while works sometimes

[tedzap]

The below is a slightly cleaned up version of what I am trying to do.

To summarize, I want to have the script watching for the *CSV TRIGGER* string, grab the file name, open a capture file using that name, capture the data, close the file, clean up after itself.

All seems to work as I wish when the PROCOMM window is first opened. If the window is left opened, there is something that seems to "break" the when-target-while continuous loop. When broken, the string will not invoke the desired response. If I go in and start up a different script and then restart this one it starts working again.

when the loop is "broken" I can see the "running man" and it appears that the script is still active. If I close the window I get the prompt asking if I want to close all scripts (like it is active).

any ideas what is fouling my continuous loop? I would like to have the script be able to respond to the trigger several times in one session. I have *not* been able to identify what (or when) is actually breaking the script. It seems to work for awhile.

Thanks,
-Ted




string file_name
string orig_capture_path
string orig_capture_file



proc main
when target 0 "*CSV TRIGGER*" call get_fname_and_capture

while 1
yield ; puts it in a continuous loop
endwhile
endproc

proc get_fname_and_capture

fetch capture file orig_capture_file ; grabs the default capture file name
fetch capture path orig_capture_path ; same for the default path

set aspect rgetchar 90 STRIP ; sets the rget end character to Z
rget file_name ; picks uf the filename

set capture file file_name ; renames the capture file name


capture on
sendkey 13 ; sends the <enter> key twice
sendkey 13 ; start the data capture
waitfor " " FOREVER
; wait for end of doc (& over-ride the 30 second default timeout)
capture off ; turns off data capture


set aspect rgetchar 13 STRIP ; resets the rget end character to default (CR)
set capture file orig_capture_file ; returns your capture file name to the default
set capture path orig_capture_path ; same with capture path
endproc

 

[kodr]

From the documentation:

Forces a procedure or function call when a particular event occurs. Once a when command is executed, it remains in effect until a when clear command is encountered, or the script terminates.

If I'm reading this correctly, you may need to add a 'when clear' to the end of your get_fname_and_capture procedure.

Not sure though, I usually only use when target to look for error conditions to stop the entire program.

proc get_fname_and_capture
   
   fetch capture file orig_capture_file     ; grabs the default capture file name
   fetch capture path orig_capture_path        ; same for the default path
   
   set aspect rgetchar 90 STRIP            ; sets the rget end character to Z
   rget file_name                ; picks uf the filename

   set capture file file_name            ; renames the capture file name


   capture on    
   sendkey 13                    ; sends the <enter> key twice
   sendkey 13                    ; start the data capture
     waitfor "                                            " FOREVER
                             ; wait for end of doc (& over-ride the 30 second default timeout)
   capture off                    ; turns off data capture
   
   
   set aspect rgetchar 13 STRIP          ; resets the rget end character to default (CR)
   set capture file orig_capture_file        ; returns your capture file name to the default
   set capture path orig_capture_path        ; same with capture path
when clear
endproc

 

[tedzap]

Thanks for the response... I tried putting in the "when clear" statement, but that simply made it a "one shot" kind of trigger.

in other words, when the trigger was seen the first time it worked properly. at the end of that procedure, the "when clear" seems to turn off the loop that is watching for the next occurance of the trigger. the next time the trigger was sent to the screen the procedure did not do anything. this is similar to the failure I am trying to resolve, but this seems to force it after once occurence.

does this make sense?

 

[kodr]

Hmm, sorry that didn't help. I'll look at some old code I have at home over the weekend.

 

[comtechau]

Your loop should be fine, so if it is getting stuck it is your called procedure that's halting.

You could test for this by temporarily deleting everything from the making your called procedure, and try this instead...

sendkey 13 ; sends the <enter> key twice
sendkey 13 ; start the data capture
usermsg "YES" and seeing if it loops around ok...

I think it might be getting stuck at the WAITFOR "x spaces" FOREVER . Are you certain the amount of spaces are always the same?. If not, maybe try WAITQUIET 5 FOREVER instead? This will require 5 seconds of terminal in-activity before the script will flow on.

http://commtechau.bravehost.com

 

[tedzap]

I expect that you are right about it getting hung in the called procedure.

Yes, I am sure about the number of spaces always being constant, I am writing the code on that end as well.

The script was having the same problem before I inserted the FOREVER qualifier on the WAITFOR. I put it in because the data dump was taking more that the standard 30 seconds- more like 60 to 90 seconds.

I guess that I could have the script return some sort of message to the user: "RETURNING FROM THE CALLED PROCEDURE" and narrow it down that way. any other good debug ideas?


thanks
-ted

 

[comtechau]

I often throw in temporary lines like USERMSG "1", USERMSG "2"... etc throughout problem scripts so I can get a better idea of which part of a script is running when it goes toes up.

One other idea.. I seem to remember a script I wrote recently with multiple captures required the use of 'CAPTURE OVERWRITE ON'. But, not sure if there is anything to that.

http://commtechau.bravehost.com

 

[knob]

You might try using Procomm's debugger to see if you can determine where the script is at when it gets stuck. I have more information at the below link:

http://www.aspectscripting.com/debug.shtml

http://www.aspectscripting.com

 

[kxboy]

Could if be that your when target is outside of your while1 - endwhile loop? The when target gets fired the
first time, then your loop starts. Once the called procedure runs, it goes back to the loop and will never see the when target again.

 

[knob]

No, that should be OK. The when target stays active until a when clear is issued, and in fact, putting a when target in a while loop can cause weird things to happen.

http://www.aspectscripting.com

 

[tedzap]

thanks for all the replies. The person I am doing this for ran a session over the weekend. he made dozen's of file captures and after 4 days it hung (same session).

I have now compiled it with "compile for debug" and also selected "create map file" and "include line numbers". I have not used this functionality before.

Obviously the problem with tracking this down has to do with reproducability. I haven't been able to do it.

With these compiler options, can I simply view the map and see where it is stuck? I am going to play around with it, but am hoping to let the end-user do the work of getting it to hang.

all tips and ideas are greatly appreciated!

 

[knob]

With the debugger, if the script hangs, you can press Ctrl-Break to find out what the script is executing at the time, and then try stepping line by line to determine where it is stuck at or if it is in a loop of some sort. You can also check the values of your variables in the debugger to see if one of them may contains some unexpected input that is blocking the script's execution.

http://www.aspectscripting.com