temporarily disabling SequenceFilePostStepRuntimeError event capture

[ryk]

I am attempting to implement an event based runtime error handler using SequenceFilePostStepRuntimeError.  In the main section of the callback I use the following select - case statement...

    Select         Parameters.Step.Result.ErrorCode

          Case          {8000, 2000, 4000, 1000}

          ...          //code to address, then verify the issues that caused the event codes are resolved.

          End

Within the case statement there is code to address the issues that can also result in these same 4 error codes.

My fear is that if the same error codes occur, will it cause an infinite recursive execution flow.

My questions are: 

1) Is the default behavior of the SequenceFilePostStepRuntimeError callback to continue to trap events even while current execution flow is inside?

2) If 1) is true, how can this callback be inhibited from any further capturing of events during the time execution flow is already in the callback?  (so perhaps do something in the setup section of the step to inhibit event capturing and re-enable event capturing in the clean-up section of the callback.)

[~jiggawax~]

If you are in SequenceFilePostStepError it will only display the error once.  It doesn't invoke the callback for the errors within itself.

So you could potentially see 2 popups.  One for the initial error and once for within the callback.   You won't see more than that.

Hope this helps,

[ryk · Accepted solution]

After reviewing the online documentation for SequenceFilePostaStepFailure Callback, and then looking at the linked example program contained in that page, the answer to my question becomes apparent: 

The very first step uses the ActiveX/COM Adapter, to set the Step.CancelStepCallback property to True to suppress any other failure callbacks for a failed step.

Right click on this step, select specify module and view the Module tab to see the settings dialog values.  Actual values for the Automation Server setting will vary depending on version of TestStand installed on your system.  Values on my system at the time of this posting are: 

Finally, although it does not mention it explicitly , I suspect that setting the same property to False (for example in the Cleanup section) will allow the callback  to resume its capability to respond to subsequent failure events prior to returning execution flow in the main sequence.