CVI DLLs skip on to the next step without completing in TestStand.

[daitken]

I have created a number of DLLs from within CVI which are run as a sequence in TestStand using the DLL Flexible Prototype Adapter. When I compile the DLLs using debug mode within CVI, they run fine within TestStand. However, when I compile them in release mode, TestStand keeps skipping on to the next test before it has completed the current one. This often leads to two or more CVI panels on screen after the failure has happened a couple of times, and leaves TestStand in a thoroughly confused and unstable state (usually resulting a blue screen).
The skips seem to happen somewhat randomly, but seem to consistently happen when the DLLs pop up a GenericMessagePopup box. Sometimes TestStand skips on as soon as
the panel for a step is displayed without doing anything and the panel just disappears.
Any suggestions as to what is going on?

Thanks in advance.

[Scott_Richardson]

Daitken -
A way that CVI could leave a panel displayed is if an exception occurs in your CVI code after displaying a panel and TestStand is the one to catch it. Now TestStand should be returning to you the error, but if you ignore it CVI can never discard the panel.

For panels that quickly just go away, I have written CVI code in the past that incorrectly allowed the user to execute an extra QuitUserInterface, which manifested itself when the next dialog to be displayed, immediatedly closing. CVI basically queues the QuitUserInterfaces. Review your code and make sure that you only Discard a panel after you return from a RunUserInterface, and make sure that when a user clicks on something that causes a QuitUserInterface that you do not do process me
ssages that might allow the user to click again on something which initiates another QuitUserInterface. If you need to process messages, make sure another QuitUserInterface is skipped until you actually return from the RunUserInterface.

Scott Richardson (NI)

[daitken]

Scott,

Thanks for the detailed response. It was an exception occuring as you suggested, hidden in an errant call to a Timer event. I'm still intrigued as to why it didn't fail when the DLL was compiled as a debug version, but my problem is solved so thanks again.

Dave

[Scott_Richardson]

Dave -
Typically a debug version of a module has non-optimized code and in the case of CVI, CVI adds a lot of runtime error checking code around function calls. These differences may make a memory location value different, i.e non-zero to zero, or zero to non-zero. A previously non-zero address might be work but it may further corrupt memory, but a zero address will always throw an exception.

Scott Richardson (NI)