From 11:00 PM CST Friday, Feb 14th - 6:30 PM CST Saturday, Feb 15th, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CST Friday, Feb 14th - 6:30 PM CST Saturday, Feb 15th, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
03-19-2013 04:25 PM
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
Solved! Go to Solution.
03-20-2013 07:50 AM
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!
03-20-2013 06:13 PM
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
03-25-2013 09:53 AM
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
03-25-2013 03:23 PM
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
03-26-2013 09:50 AM - edited 03-26-2013 09:51 AM
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
03-26-2013 11:06 AM
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!
03-26-2013 06:06 PM
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