09-19-2013 10:07 AM
Hi all,
Building my own TS GUI, I use the TS components in a VI that's never shown (running as a 'service' in my app).
Another window is used as the main GUI and 'lives' according to orders sent from my TS 'service' VI (orders sent upon UIMessages' data).
My problem is that when a run-time error occur running a sequence, the runtime error dialog is shown but it also shows my 'service' VI front panel... Why is that ?
I guess there is something related to windows handles...
What can I do to avoid this behavior ? I only want the runtime error dialog to show up to my main front panel....
Thanks
Solved! Go to Solution.
09-20-2013 09:47 AM
Not sure this will work, but you might try setting Engine.AppMainHwnd
-Doug
09-20-2013 09:50 AM
Thanks for the advice, I'll give it a try and let you know.
Is there a chance that this will perturb other TS API controls/actions placed on 'service' VI ?
09-23-2013 05:40 AM
Hi !
I tested the solution to give the hWnd number of my top-level window to TS Engine.HWnd. It doesn't create any error but it still shows my TS hidden VI.
On this VI are placed TS ActiveX controls such as ExecutionView.
Does these controls require to be visible when the run-time error dialog pops up ?
If yes, instead of disconnecting these controls (I'd like to keep them active to vizualise the execution flow on certain circumstances) is there any way to disable this beavhior ?
09-23-2013 10:03 AM
Oh, it's probably because of the execution view control then, not the dialog. When the execution is displayed for the runtime error, the parent of the execution view control is probably being activated.
You can override the UI controls handling of the runtime error entirely by using the ApplicationMgr.UIMessageEvent and setting the cancel parameter to true if the event is UIMsg_BreakOnRunTimeError.
You will then have to handle the UIMessage entirely yourself though in order to display the runtime error dialog, so perhaps it's not worth it. Could you perhaps put the executionview control on a different window that you do want to be visible? Or maybe at least try it temporarily to let us know if that is the cause of the problem. Also what version of TestStand are you using?
-Doug
09-23-2013 10:30 AM
Hi Doug,
I finally found the solution. In the LV API there is a callback VI named 'DisplayExecution' which brings the VI identified as the top-lvl one (done in the API intialization (TopLevel refnum global)) to be the toplevel window.
This callback VI is played on every execution break, so it's also played on run-time error.
Disabling this VI resolves the problem.
Thanks for your help !
09-23-2013 11:04 AM
Cool, glad you figured out the cause. The UI controls will fire the DisplayExecution event for various UI messages, so what you found makes sense.
-Doug