TestStand SequenceFilePostStepRuntimeError callback dialog and behavior

[vrv]

Hi,

NI have an example of overriding the default behavior of the runtime error handling: "\Examples\Fundamentals\Overriding Engine Callbacks\Overriding SequenceFilePostStepRuntimeError Callback.seq".

Instead of the "Choose Action" dialog I want to use the build in Runtime Error dialog by calling "Runstate.Engine.DisplayRunTimeErrorDialogEx ( dlgTitle, sequenceContextParam, dlgOptions, suspendExecution, dontShowAgainForExecution, dontShowAgainForBatch, runTimeErrorAction)"

I would like to break feature. This is not a part of the example. Calling "RunState.Caller.Execution.Break()" make the execution break immediately and not at the "executed step". Problem is the execution is the same for my test step and and the callback.

Suspending the thread "RunState.Caller.Thread.ExternallySuspended = True" is a bad idea.

I've tried dynamic inserting a breakpoint "RunState.CallingStep.SetBreakSettings ( isSet, enabled, passCount, Condition, [executionParam])". This works but leave a breakpoint which the user manually must clear.

Anyone who knows how to break without setting a breakpoint?

(I know it is possible to do what ever I need to do in the RuntimeError callback showing no dialog and NOT set the ErrorReported flag "RunState.Caller.RunState.ErrorReported = true" causing the native runtime error dialog also to occur and this takes care of the problem.)

[pschroeder]

I am experiencing this same issue.  I am handling Runtime errors with a custom dialog VI from the StationPostStepRuntimeError callback placed in the StationCallbacks.seq file.  When I attempt to Break the execution with the Caller SequenceContext.Execution.Break method, the execution breaks in the callback instead of the step where the runtime error was generated.  I believe this is the same issue you are describing. The desire is to have the sequence break on the test step and not within the callback.

Was a solution ever found for this issue?

[pschroeder]

I opened a ticket with NI and sought a solution to this issue.  The solution that NI provided was to instead of the Break method, use the Execution.StepOut method.  NI described using a conditional expression where the StepOut method is called, in the step following my custom error dialog VI, with a variable Local.Break set by the VI:

Locals.Break? RunState.Execution.StepOut() : False

After testing, I pushed the method call into my error handler VI and got the same effect.  The one issue that I found is that in cases where I attempt to Terminate and Break the execution at the same time, the first time the execution will begin to terminate, but not Break.  If a second RTE occurs during the termination cleanup, and the Terminate and Break methods are used again, the execution will then Break.