run-time error dialog : avoid showing it's parent window

[CyGa]

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

[dug9000]

Not sure this will work, but you might try setting Engine.AppMainHwnd

-Doug

[CyGa]

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 ?

[CyGa]

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 ?

[dug9000]

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

[CyGa · Accepted solution]

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 !

[dug9000]

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