Archived: TestStand 4.0 Known Compatibility Issues

NI does not actively maintain this document.

This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.

Overview

This document has been archived and is no longer updated by National Instruments.

This document contains the TestStand 4.0 known issues that were discovered before and since the release of TestStand 4.0. Not every issue known to NI will appear on this list; it is intended to only show the severe and more common issues that can be encountered.

Acquiring Licenses for Applications

In previous versions of TestStand, an application attempts to acquire a license when the ApplicationMgr control creates the engine or when the application directly creates the engine. In TestStand 4.0, a license is not acquired when creating the TestStand engine. Instead, an application attempts to acquire a license when the application calls ApplicationMgr.Start, calls ApplicationMgr.IsEditor after calling ApplicationMgr.Start, or calls Engine.AcquireLicense. If the application does not acquire the appropriate license, calling methods such as Engine.NewSequenceFile, Engine.GetSequenceFile, and SequenceFile.Save also attempt to acquire a license.

Using LabVIEW 8.x

Refer to Appendix A, Using LabVIEW 8.x with TestStand, in the Using LabVIEW with TestStand manual for more information about LabVIEW features supported in TestStand and whether there are any associated limitations.

Using Microsoft Visual Studio

TestStand 4.0 installs the .NET Framework 2.0. The TestStand Sequence Editor, the new TestStand User Interface Variables View and Insertion Palette controls, and the .NET Adapter require .NET Framework 2.0.

You cannot use Microsoft Visual Studio 2003 to debug managed code in the TestStand process if TestStand loads the .NET Framework 2.0. Instead, you must use Microsoft Visual Studio 2005.

You can no longer use Microsoft Visual Studio 2003 to directly step into code modules from TestStand. Instead you must use Microsoft Visual Studio 2005. You can still manually attach and debug the TestStand process from Microsoft Visual Studio 2003.

In previous versions of TestStand, the .NET Adapter and the C/C++ DLL Adapter initiated mixed mode debugging (managed and native) when stepping into a code module and automatically attached Microsoft Visual Studio to the TestStand process. In TestStand 4.0, the .NET Adapter initiates only managed debugging, and the C/C++ DLL Adapter initiates only native debugging. To initiate mixed mode debugging in TestStand 4.0, you must manually attach and debug the TestStand process from Microsoft Visual Studio.

Operator interfaces based on the C# or VB.NET full-featured operator interface examples from TestStand versions earlier than 4.0 exhibit slow and flashy menu operation if you recompile them using the .NET 2.0 Framework instead of the .NET 1.1 Framework. To alleviate this issue, call the new NationalInstruments.TestStand.Utility methods Menus.BeginUpdate and Menus.EndUpdate, as shown in the TestStand 4.0 full-featured user interface .NET examples.

TestStand 4.0 changed the drawing and resizing code for the User Interface (UI) Button control to address changes between the .NET 1.1 Framework and the .NET 2.0 Framework. If you run an application that uses the TestStand UI Button control with the .NET 1.1 Framework, the control font and the size of the control might be incorrect. Use the .NET 2.0 Framework instead.

TestStand 4.0 installs dynamic help for Microsoft Visual Studio 2005 only. TestStand 3.5 installed dynamic help for Microsoft Visual Studio 2003 only. Access the NI TestStand Help by selecting Start»All Programs»National Instruments»TestStand 4.0»Online Help»NI TestStand Help or by selecting Help»NI TestStand Help in the TestStand Sequence Editor.

Change in Search Order for Subordinate DLLs for LabWindows/CVI and C/C++ DLL Adapters

The order in which the LabWindows/CVI and C/C++ DLL adapters directories search for subordinate DLLs has changed. Subordinate DLLs are DLLs that are called by DLLs that the adapters call directly. In TestStand 3.5 and earlier, when the LabWindows/CVI or C/C++ DLL adapter searches for subordinate DLLs, it searches first in the directory that contains the application that loaded the adapters, typically the sequence editor or an operator interface. In TestStand 4.0, when the LabWindows/CVI or C/C++ DLL adapter searches for subordinate DLLs, it searches first in the directory that contains the DLL it calls directly.

In TestStand 3.5 and earlier, when the LabWindows/CVI or C/C++ DLL adapter calls a DLL directly, the adapter temporarily sets the current working directory to the directory where the DLL resides. As a result, the adapter finds subordinate DLLs in the same directory as the DLL it calls directly because the OS search directory precedence for subordinate DLLs includes the current working directory. The order in which directories are searched to locate subordinate DLLs in TestStand 3.5 and earlier is as follows:

  1. The directory that contains the application that loaded the adapter.
  2. The current working directory of the application, which the adapter has set to the directory that contains the DLL it is calling directly. (Windows 2000 and Windows XP Service Pack 1 and earlier)
  3. The Windows\System32 and Windows\System directories.
  4. The Windows directory.
  5. The current working directory of the application, which the adapter has set to the directory that contains the DLL it is calling directly. (Windows XP Service Pack 2 and later)
  6. The directories listed in the PATH environment variable.

In TestStand 4.0 and later, the adapters attempt to load subordinate DLLs without setting the current working directory and use an alternate search directory precedence that includes the directory that contains the DLL being loaded as follows:

  1. The directory that contains the DLL that the adapter is calling directly.
  2. The current working directory of the application. (Windows 2000 and Windows XP SP1 and earlier)
  3. The Windows\System32 and Windows\System directories.
  4. The Windows directory.
  5. The current working directory of the application. (Windows XP SP2 and later)
  6. The directories listed in the PATH environment variable.

Notice that the list of directories that TestStand 4.0 searches does not explicitly include the directory that contains the application that loaded the adapter. For backward compatibility, if a TestStand 4.0 adapter fails to load a DLL, the adapter attempts to load the DLL using the same approach used in TestStand 3.5 and earlier. National Instruments does not recommend placing subordinate DLLs in the directory that contains the application that loads the DLL because loading subordinate DLLs from this location might not be supported in the future.

New Default for FontSource Properties

In TestStand 3.5 and earlier, the default value for font source properties that TestStand UI Controls use is FontSource_UseFontProperty. In TestStand 4.0 and later the default value is FontSource_UseGUIFont. This change affects existing applications that dynamically create TestStand UI Controls. When you rebuild an application using TestStand 4.0, control properties values do not automatically change, so you must manually update these controls if you want to use the new default font source setting.

This behavior change applies to the following control properties:

  • Button.FontSource
  • CheckBox.FontSource
  • ComboBox.FontSource
  • ExpressionEdit.FontSource
  • Label.FontSource
  • ListBox.FontSource
  • ListBar.ButtonFontSource
  • ListBar.PageFontSource
  • SequenceView.CommentsFontSource
  • SequenceView.HeaderFontSource
  • SequenceView.TextFontSource
  • StatusBar.FontSource

Note  The default font for ReportView.TextReportFontSource is FontSource_UseSystemFixedWidthFont and has not changed.

Engine.Reload

All global variables and their sub-properties of type Reference that still exist after you call the Engine.ReloadGlobals method now retain the reference values they had before the call to ReloadGlobals. In previous versions, reloading the globals cleared all global reference values.

Sequence Editor Call Stack

The first item in the call stack is now the most nested sequence invocation.

User Interface Configuration File

The Application Manager saves configuration information in the <UserProfile>\Local Settings\Application Data\National Instruments\<TestStand>\ directory. In previous version of TestStand, the Application Manger used the OperatorInterface.ini file. TestStand 4.0 uses the UserInterfaces.xml file.

Make Step Names Unique When Inserting Steps

The default setting has changed for the Make Step Names Unique When Inserting Steps option located in the Sequence Editor Options dialog box. In TestStand 4.0, the setting is disabled. In TestStand 3.5 and earlier, the default setting is enabled. Use the Sequence Editor Options dialog box to change the setting.

For TestStand Custom Sequence Editors, use ApplicationMgr.MakeStepNamesUnique to specify whether the application ensures that steps you insert into a sequence have names that are unique within the sequence.

Default Limits and Comparison Values

The default limits and comparison values for the test step types in TestStand 4.0 have changed. If you do not configure the limit or comparison value, the step fails. The default limits for the Numeric Limit Test and Multiple Numeric Limit Test are now "9 <= x <= 11", the default Boolean value for the Pass/Fail Test is False, and the default comparison string for the String Value Test is "<Specify your expected value here>". This change does not affect existing steps.