Accessing Error Message Properties when using DisplayRunTimeErrorDialogEx Method

[David_Jackson]

I have a custom error handing callback that displays the standard run-time error dialog using the Engine.DisplayRunTimeErrorDialogEx method. http://zone.ni.com/reference/en-XX/help/370052H-01/tsapiref/reftopics/engine_displayruntimeerrordial....  The parameters of this do not allow me to specify details about the error message available (via the calling step's error properties).  However, when the built in TestStand processes display the run-time error dialog via its built in error handling methods it somehow manages to fill in the details about the error.

Does anyone know how I can populate the details and error code fields of the dialog box when using the DisplayRunTimeErrorDialogEx method to call this? See attached screenshot for an exmaple of what I get when I use this method.

Regards,

David

[Daniel-E]

Hey David,

You can do this by setting the Step.Result.Error container before displaying the error box. I did the following in a Statement step in TestStand (a similar approach will work with the TestStand API from an external application):

Step.Result.Error.Code = 10,
Step.Result.Error.Msg = "This is a custom error message",
RunState.Engine.DisplayRunTimeErrorDialogEx("Test Error",ThisContext,0,0,0,0,0)

 Also, note that the last several arguments to the DisplayRunTimeErrorDialogEx would normally be values that we'd want to save, since they correspond to the choices the user makes on the error screen.

This should let you set the values in the box, but if you have any more trouble with it, just let us know!

[David_Jackson]

Hello  Daniel,

Thanks for the suggestion.  Setting the Step.Result properties in a separate statement step immediately before the step that calls the DisplayRunTimeErrorDialogEx method did not work for me.   I also tried setting the NextStep properties (i.e. of the step that calls the DisplayRunTimeErrorDialogEx method) and that did not work.  What did work though was setting the Step properties of the step that executes the DisplayRunTimeErrorDialogEx method in a pre-expression, so I have a solution.

By the way, I do track and handle the user's choices returned by the DisplayRunTimeErrorDialogEx method.  I use an Execution.StepOut expression if the user chooses the Break option (which causes the execution to break at the next step following the error), and reset the Runstate.Execution.RTEOptionForThisExecution to the value returned by the method if the user chooses not to display the dialog for the remainder of the execution

Thnaks for the idea.

Regards,

David

[dug9000]

You could also probably pass the sequence context for the sequence that had the error (assuming you are in a callback error handling sequence).

-Doug

[David_Jackson]

HI Doug,

Yes, my error handler is coded in a PostStepRuntimeError callback sequence that has visibility of the calling step's properties.  Although I could access the calling step's Result.Error container properties (containing the error details) I could not display them in the runtime error dialog.  I found that I needed to set Step.Result.Error properties of the statement step that launches the Runtime Error Dialog as a pre-expression to the values from my calling step (that had the error) to get these to display.  I do not know why this works, but assume that the internal process of the DisplayRunTimeErrorDialogEx method accesses these.   It would be nice if the API documentation mentioned this though.

Regards,

David

[dug9000]

I think it's the sequence context that you pass into the API that controls what step it looks at. If you pass the sequence context for the calling sequence then it will look at the step that actually generated the error.

-Doug

[Al.B · Accepted solution]

Doug is correct; each sequence in the call stack has its own sequence context, so if you just pass in "ThisContext" for the sequence context parameter, you are providing the context of the error callback, which has no error.  To access the context of the sequence which errored, you need to use the caller property to get the next level up in the call stack, e.g.:

RunState.Engine.DisplayRunTimeErrorDialogEx("Error Dialog",ThisContext.Caller,0,False, False, False,False)

Hopefully this clarifies!

[David_Jackson]

Thanks Al B and Doug.  Yes, passing ThisContext.Caller solves the issue.  Previously I was just using ThisContext.  You learn something new every day.

Regards,

David