LabVIEW 8.6 Known Issues
PrintOverview
This document contains the LabVIEW 8.6 known issues that were discovered before and since the release of LabVIEW 8.6. 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. Each Issue appears as a row in the table and includes an issue title, a brief description of the problem, any workarounds that might help resolve the issue, and the date the issue was added to the document (not the reported date).
The issues appear in two tables which each contain the same information:
- Known Issues by Category - This table sorts the issues by category. This table is recommended for use in helping determine if an issue has been reported to us, and is also recommended for users wanting to skim the document to learn of potential issues they may face with this version of LabVIEW during development.
- Known Issues by Date - This table is a flattened list of all issues sorted only by the date the issue was added to the document. Use this table to quickly locate the most recently reported issues.
The workarounds that appear in the document are not always tested by NI and are not guaranteed to resolve the issue. If a workaround refers you to the NI KnowledgeBase, please visit www.ni.com/kb/ and enter that KB number in the search field to locate the specific document. The brief description given does not necessarily describe the problem in full detail, and it is expected that you might want more information on an issue. If you would like more information on an issue feel free to contact NI and referencing the ID number given in the document. The ID number contains the current issue ID number followed by the legacy ID number (if available). Use the current ID number when contacting National Instruments. You can contact us through any of the normal support channels including phone, email, or the discussion forums. See www.ni.com/ask to contact us. Also consider contacting us if you find a workaround for an issue that is not listed in the document so that we can add the workaround to the document.
Known Issues by Category
The following items are known issues in LabVIEW 8.6 sorted by Category.
| ID | Known Issue |
|---|---|
| Building and Distributing LabVIEW Applications | |
| 53817 4I6CKJ00 |
Adding password protected VI to a library while building an application causes a password dialog to appear When building an application with "Add files to new project library" selected on the Destinations page, if the application includes any password protected vi.lib subVIs you will be prompted to enter these passwords. Workaround—You can cancel the prompt for the password, which may produce a Load Warning dialog. You can also cancel the Load Warning dialog and the operation will complete. Date Added—04/29/2008 Return to top |
| 100288 | After installing LabVIEW 8.6, function names of .dlls created in LabVIEW cannot have more than 32 characters when built using versions earlier than LabVIEW 8.6 LabVIEW installs a component for building shared libraries that is shared with all versions of LabVIEW on the local computer. This component has additional checks which limit the length of function names to 32 bits. Earlier versions of LabVIEW did not have this limit. Since the new component was registered in the end, all the other versions of LabVIEW will use it during the build process, thus creating an error. Workaround—Workaround 1: Shorten the function name to be less than 32 characters in previous LabVIEW versions. Workaround 2: Run [LabVIEW]\applibs\lvdllbuilder\lvdb.exe from an older LabVIEW installation (<8.6) when building non-LabVIEW 8.6 targets. Date Added—07/10/2008 Return to top |
| 112751 | Build Errors when VI Names are Identical but Capitalized Differently A build error occurs when building applications (executables) with VIs (including Dependencies) that have identical names and only differ in their capitalizations. The build ends up being unsuccesful with the Possible Reasons being "Error Copying Files". The VI listed in the error window is the VI which has the similar name. Workaround—Use LabVIEW Search (Edit Menu >> Find Project Items) to find the VIs which have the same name and rename them to make the capitalization identical. Date Added—07/29/2008 Return to top |
| 119615 4EI92JAI |
Application created after converting a build script is missing menu bar. Application created after converting a build script is missing menu bar. When updating a .bld file to the current LabVIEW version, the value of some VI properties are incorrectly set. This problem exists in LabVIEW 8.5 and 8.6 but not 8.5.1. Workaround—In the Source File Settings page of the build specification, select the VI and press the "VI Settings" button. Verify the settings are as expected. Date Added—08/01/2008 Return to top |
| Controls and Indicators | |
| 50061 42NAR8SA |
Center justified tables display improperly when overlapping with the front panel origin When you add a table control to the front panel so that it overlaps with the vertical origin of the front panel, LabVIEW displays center justified columns off center when you type text. The cells appear to float or move horizontally until aligned with the vertical origin. Workaround—Move the table away from the front panel's vertical origin. Date Added—09/01/2007 Return to top |
| 51311 477DKPBQ |
LabVIEW does not maintain child-only item setting when dragging an item within a tree If you have a tree item with the child-only setting, and then drag it within the tree, LabVIEW loses the child-only setting. Workaround—Use tree events to (1) get the child-only flag setting when the user begins a drag, and (2) reset the child-only flag after completing a drop. Date Added—09/01/2007 Return to top |
| 52297 4AIFC0R0 |
Internal error related to locked tab control at fpsane.cpp line 369 and line 367. If you lock a tab control that is already locked using Group»Lock, you might see two internal errors and LabVIEW may crash. Workaround—Do not lock a control that is already locked. Date Added—09/01/2007 Return to top |
| 88787 3J0A89J1 |
Zero element clusters not reported as an error for Type Defs/Custom Controls Type Defs should not contain zero element clusters, but LabVIEW does not report an error if you have a type def with zero elements. Workaround—Do not save a zero element cluster. Date Added—09/01/2007 Return to top |
| 91672 477M7K00 |
Large amounts of data in combo box can appear to hang LabVIEW. If you place a large amount of data in a combo box, on the order of megabytes, LabVIEW appears to hang by taking a long time to calculate wrapping. Workaround—N/A Date Added—09/01/2007 Return to top |
| 41148 4D1JQKJ7 |
Unable to change the Display Format for Y-axis in a dynamic data type Waveform Chart/Graph The display format for the y-axis cannot be changed in a waveform chart/graph if it is configured to receive the dynamic datatype (i.e. it will be blue on the block diagram). Workaround—Configure the y-axis formatting when the graph is not in dynamic datatype mode by deleting any dynamic data wires and rewiring with a waveform. Then you can rewire with the dynamic data. Date Added—09/13/2007 Return to top |
| 41224 4DA24FXR |
Cannot display extended types on intensity plots In LabVIEW 8.0 and newer, when you wire extended precision type numbers to an intensity graph or chart you get a different looking plot than with the same double-precision numbers. Workaround—Use the data type conversion functions to convert your data to double precision representation. Date Added—09/26/2007 Return to top |
| 37476 44H8J3ZP |
Digital Display Legend Doesn't Adjust for Number of Plots in Executable In the LV Development environment, when the number of plots are changed dynamically, the Digital Display for each plot is dynamically added or removed from the legend. However, when run in an executable, the plot glyph is updated correctly, but the digital displays is not added or removed when the number of plots is changed dynamically. Workaround—Please refer to NI KB 2I6H445F for more information about this problem and workaround. Date Added—12/12/2007 Return to top |
| 43109 4FRF0826 |
Cannot customize plot legend with background image in LabVIEW 8.6 You cannot configure a plot legend with a custom background image in LabVIEW 8.6. Workaround—Make the color of the plot legend transparent, and place the image behind it. This only works if your plot legend remains a fixed size in a fixed location. Date Added—01/23/2008 Return to top |
| 45133 4I0976O4 |
The coercion of an enum through its digital display behaves differently in the development environment than in a LabVIEW executable. The coercion of an enum through its digital display behaves differently in the development environment than in a LabVIEW executable. Neither produce an out of range value, but one coerces to the last entry in the enum, the other leaves the enum unchanged. Workaround—Use an event structure to capture value change filter events and restore the enum to the value you choose. You can also disable the digital display for the enum. Date Added—02/22/2008 Return to top |
| 100580 | Dropping control references may cause Data Change event for XControl Dropping a control/indicator reference onto a VI that is hosting an XControl, whose data type is an array, will cause a Data Change event to be handled by the facade VI of the XControl. Workaround—N/A Date Added—07/09/2008 Return to top |
| 118949 | Tab control local variables generate value change events when you use a multi-column listBox A value change event is generated when a Tab Control local variable's value is changed in an Event Structure that was triggered by a double-click/ value Change on a multi-column listBox.. Workaround—Use Value Property Node for the Tab Control instead of Local Variable to change the Tabs. Date Added—07/10/2008 Return to top |
| 119444 | Mulicolumn listbox format lost on upgrade A Multicolumn listbox created in LV 7.1 may lose its format when opened in LV 8.5 or later. Column headers lose their 3D appearance and font formatting might be lost. Workaround—Replace the Listbox and recreate all customizations Date Added—07/12/2008 Return to top |
| DataSocket | |
| 37020 4A37JOV9 |
DataSocket functions do not handle Domain security correctly. The DataSocket Open function returns error 1179 for any attempt to connect to a shared variable that has security enabled, even if the correct user is logged in. Workaround—Drop a shared variable node on the block diagram and run the VI once; you can delete the variable node and DataSocket security will continue to work. Date Added—09/01/2007 Return to top |
| 46630 2VO0SF00 |
DataSocket/OPC Leaks Memory when repeatedly using ActiveX VIs to perform open-write-close If you call the DataSocket Open, DataSocket Write, and DataSocket Close functions in succession repeatedly, LabVIEW leaks memory. Workaround—To correct this problem, call the DataSocket Open function once, use the DataSocket Write function to write multiple times, and then use the DataSocket Close function. Date Added—09/01/2007 Return to top |
| 47103 3BS49JS8 |
dialog box and open datasocket conflict If a dialog box is already open, you cannot use the DataSocket Open function. Workaround—N/A Date Added—09/01/2007 Return to top |
| 47977 3OLE2573 |
DataSocket and Fixed Size Array Do Not Work You cannot use front panel DataSocket data binding with fixed-sized arrays. Workaround—Uncheck autopreallocate arrays and strings in the VI properties execution category for all VIs not intended to run on an FPGA. Date Added—09/01/2007 Return to top |
| Documentation | |
| 118200 | Discrepancy in TCP Read help There is a problem with the documetation about operating a native LabVIEW TCP Read function in CRLF mode. The LabVIEW help says if you request n bytes and there is no CRLF in the n bytes, the function should timeout, return no bytes, and return an error. This is not what happens - if there are at least n bytes available at the port, the function returns the n bytes and no error regardless of whether there is a CRLF in the string. If there is a CRLF in the string, it just returns the string up to and including the CRLF as advertised. If there are less bytes at the port than the bytes requested, it times out and returns an error. Workaround—N/A Date Added—07/07/2008 Return to top |
| 121012 | Report type input of New Report.vi is a required input Report type input of New Report.vi is a Required input in LabVIEW 8.6. Workaround—Manually create an input control/constant. Date Added—07/22/2008 Return to top |
| 121017 | Nonlinear System Single Solution.vi and Nonlinear System Solver.vi are replaced with nD Nonlinear System Single Solution.vi and nD Nonlinear System Solver.vi respectively The new versions of the VIs are set as reentrant. Workaround—Replace the old VIs with the new versions. Date Added—07/22/2008 Return to top |
| 121210 4CLA8LN8 |
Save for Previous now requires you to enter a password for all password-protected VIs Save for Previous now requires you to enter a password for all password-protected VIs. This also applies to Save for Previous calls made programmatically. Workaround—Enter a password for protected VIs. Date Added—08/01/2008 Return to top |
| 121994 | 3D Graph on Palette in Base LabVIEW Non-Functional The 3D graph is not functional in Base LabVIEW development system. This Indicator requires LabVIEW Full or Professional to be functional. The 3D graph requires the full runtime engine, it will not function with only the minimum runtime engine installed. Workaround—Install LabVIEW Full or Professional Development Environment. Date Added—08/01/2008 Return to top |
| File I/O | |
| 47436 3IKBUP99 |
Zip build provider and Zip VIs do not support multi-byte character encodings. The Zip build provider and the underlying Zip API provided in the File I/O palette do not support paths with multibyte character encodings. Some upper or lower bytes of multi-byte characters decode into disallowed ASCII characters when not configured correctly. Workaround—Ensure that the full filepath to zipped files does not contain multi-byte characters. Date Added—09/01/2007 Return to top |
| 47819 3N68LE00 |
2GB file size limit of datalog files The maximum size of datalog files is 2 GB. Workaround—N/A Date Added—09/01/2007 Return to top |
| Functions, VIs, and Express VIs | |
| 37575 3PD8N0M8 |
LabVIEW uses large amounts of memory when reading an entire wave file at once The Sound File Read VI uses large amounts of memory to read an entire .wav file. Workaround—Read the data from the .wav file in sections rather than in one large file. Date Added—09/01/2007 Return to top |
| 39161 401FEQTL |
The device ID input of the Play Sound File VI does not work on Windows On Windows, LabVIEW ignores the device ID input of the Play Sound File VI. This VI plays sound only on the default sound card. Workaround—Use the Sound Output Configure VI and the Sound Output Write VI with the Sound File Open VI and the Sound File Read VI or the Sound File Simple Read VI. Refer to the Sound File to Sound Output example VI for an example of this workaround. Date Added—09/01/2007 Return to top |
| 41530 4DJFJM00 |
Advanced Storage VIs Do Not Work in a LabVIEW Development System with a Different Language If you move the Advanced Storage VIs to a LabVIEW development system with a different language, the VIs do not work because the object types and property names do not match the names in other languages. Workaround—To correct this problem, use the internal, language-independent object types and property names. Refer to KnowledgeBase 377C3NHB at ni.com for more information about correcting this problem. Date Added—09/01/2007 Return to top |
| 41531 4DJFK100 |
If you create a new, untitled VI while using the Storage VIs, the numbering of the untitled VI might be inconsistent. If you create a new, untitled VI while using the Storage VIs, the numbering of the untitled VI might be inconsistent. Workaround—N/A Date Added—09/01/2007 Return to top |
| 47891 3NRGJTI7 |
Sound Output Set Volume VI doesn't set the volume on a per-channel basis The Array instance of the Sound Output Set Volume VI does not use the volume input to set the volume on a per-channel basis. Instead, this VI uses the first element of the volume input as the sound level for all channels. Workaround—N/A Date Added—09/01/2007 Return to top |
| 48016 3P7CBB4Q |
Unsigned int32 loses value in formula node when you write to the most significant bit If you wire a hex value greater than x7FFFFFFF as an unsigned, 32-bit integer to a Formula Node, LabVIEW coerces the value to 0. Workaround—Use signed 32-bit integers instead of unsigned 32-bit integers in the formula node. Date Added—09/01/2007 Return to top |
| 50420 44CG88SN |
Update the Pulse Transition Measurement Express VI The terminology and measurement definitions for the Transition Measurements VI comply with IEEE Standard 181-2003, IEEE Standard on Transitions, Pulses, and Related Waveforms. However, the Timing and Transition Measurements Express VI does not comply with this IEEE Standard. Workaround—The Slew rate refers to the transition slope. The Preshoot refers to the pre-transition undershoot (rising pulse) or the pre-transition overshoot (falling pulse). The Overshoot refers to the post-transition undershoot (rising pulse) or the post-transition overshoot (falling pulse). Date Added—09/01/2007 Return to top |
| 51084 4709CDDV |
Match Regular Expression function might cause stack overflow with some inputs Certain regular expressions might cause a stack overflow on large input strings. Some regular expressions might recurse repeatedly while LabVIEW attempts to match a large string that might overflow the stack eventually. For example, the regular expression (.|\n)*A and a large input string might cause LabVIEW to crash. Workaround—Rewrite the regular expression to avoid recursion. For example, to avoid recursion you can rewrite the regular expression (.|\n)*A as (?s).*A. The (?s) notation indicates that a period (.) matches new lines. You also could rewrite the expression more efficiently as [^A]*A. Date Added—09/01/2007 Return to top |
| 52263 4AJA41TQ |
Some operations on integer waveforms lose dt value Some functions, such as Absolute Value and Logarithm Base 10 operate as you expect with DBL Waveforms, but when you apply the same functions to an I16 waveform, for example, the Absolute Value function works as you expect while the Logarithm Base 10 function loses the sampling interval dt value. LabVIEW resets the sampling interval dt value to 1.00. Workaround—Extract the Y-array of the waveform and perform the needed operations on Y before re-building the waveform. Date Added—09/01/2007 Return to top |
| 54942 41CE6I39 |
Storage VIs do not recognize DIAdem date/time channels The Storage VIs do not recognize the date/time format used in DIAdem date/time channels. When you use the Storage VIs to read data from a DIAdem date/time channel, LabVIEW converts the date/time data to a double-precision, floating-point number that represents the number of seconds since 01/01/0000. Workaround—After LabVIEW converts the DIAdem date/time data to a double-precision, floating-point number, you can convert the double-precision, floating-point number to a more meaningful value. Date Added—09/01/2007 Return to top |
| 90497 3YJ87JCM |
Write to Clipboard Method takes minutes and a lot of CPU If you try to copy a large amount of data from LabVIEW to the clipboard, LabVIEW slows significantly and might become unresponsive. Workaround—N/A Date Added—09/01/2007 Return to top |
| 94566 | Probes on a cluster containing an IMAQ image always fail to load Right-clicking to create a probe on a cluster that contains an image returns error "Failed to load or create probe". This worked in LabVIEW 8.0 and 8.2. Workaround—Create custom probe without IMAQ image. Date Added—06/20/2008 Return to top |
| 96735 | Wiring Invalid File Refnum to Deny Access function crashes LabVIEW When using the Deny Access primitive, if an invalid reference number (including a null reference constant) is passed to this reference input of the function, it will crash LabVIEW. Workaround—Ensure an invalid reference number isn't passed to this VI. Date Added—06/26/2008 Return to top |
| 118373 | Subtraction and subsequent Add or Subtract operations using 2D array types might produce incorrect results with 64-bit integer data types Adding or subtracting 2D arrays when using array controls (as opposed to constants) with I64 or U64 representation can return incorrect results. This also affects any other add/subtract operation that maybe wired to one of the array controls. However, independently the add function is not affected. This occurs in LabVIEW 8.0 and 8.2 as well. Workaround—This does not happen in all cases; if the 2D array is wired through functions or if other operations occur before the initial subtraction the problem may not exist. If you test the code and discover the problem, multiply the second input to the subtract by -1 and replace your subtract with an add primitive. Add a note to your code where this operation is done so that future reviewers of you code understand why you implemented this workaround. Date Added—07/08/2008 Return to top |
| 117426 | Function block property page cannot be loaded when the function block name is blank Do not leave the name field blank on the function block. Doing so results in an error when loading the property page. The affected function blocks are currently only distributed with LV Real-Time. Workaround—N/A Date Added—07/09/2008 Return to top |
| 45802 4IDA53I0 |
Using VI Server Get/Set [Variant] Control Values on Clusters with Fixed Size Arrays creates error 2 The VI Server get/set [variant] control values if used on a cluster with fixed sze arays, results in an error. This is expected as LabVIEW core does not support fixed size arrays. Fixed size arrays are meant to be used only with LabVIEW FPGA. Workaround—Change fixed size arrays to variable size arrays. Please see KB 4FED3500 and KB 3OEDG5XL at www.ni.com for more information about Fixed Size Array Behavior and how to change it. Date Added—07/10/2008 Return to top |
| 118106 | Variant To Flattened String and Flattened String To Variant Do Not Support Fixed Point Data Type The Fixed Point data type is not supported by the Variant To Flattened String and Flattened String to Variant functions. You may see a crash when trying to unflatten this datatype in conjunction with an empty fixed point array. Workaround—Either use a supported datatype or do not use the Variant. Date Added—07/11/2008 Return to top |
| 120864 | Append VI List of SubVIs to Report does not include Express VI Configuration Information by default The "include Express VI configuration information (T)" input of Append VI List of SubVIs to Report VI is not True by default, hence it does not include the Express VI configuration information if it's not explicitly mentioned. Workaround—Do not use the default value. Create a control/constant and wire the required value. Date Added—07/22/2008 Return to top |
| Import Shared Library Wizard | |
| 36889 4999TKGI |
Import Shared Library wizard cannot recognize a function if the function declaration contains a default value In the Import Shared Library wizard, LabVIEW cannot recognize a function in a header (.h) file if the function declaration contains a default value for a function parameter. Workaround—Remove the default values of parameters in the header file. Instead, add the default values to the Configure VIs and Controls page of the Import Shared Library wizard. Date Added—09/01/2007 Return to top |
| 37271 45I650CI |
The Import Shared Library wizard does not support macros inside of function declarations The Import Shared Library wizard does not support macros inside of function declarations in the header (.h) file. Workaround—Move any macros outside of function declarations in the header file. Date Added—09/01/2007 Return to top |
| 37448 44CEN7MQ |
Import Shared Library wizard cannot recognize multiple function declarations in a row If you have a header (.h) file that contains multiple function declarations in a row, the Import Shared Library wizard recognizes only the first function declaration. Workaround—Separate the function declarations in the header file. Date Added—09/01/2007 Return to top |
| 39823 4AIGSL00 |
The progress bar in the Import Shared Library wizard appears to hang When you use the Import Shared Library wizard, LabVIEW displays a progress bar. This progress bar might appear to hang, even though the tool is working correctly. Workaround—Wait until the generation finishes. Date Added—09/01/2007 Return to top |
| 64258 4B9MOUMX |
Import Web Service wizard fails to expand the .NET reference when the reference is in an array The Import Web Service wizard expands the .NET reference and returns all its properties. However, when the .NET reference is in an array, it returns only the reference, not its properties. Workaround—Use the Index Array function and a Property Node to get the properties of the .NET reference. Date Added—09/01/2007 Return to top |
| Installation and Activation | |
| 67845 4DJE9C3A |
LV attempts to repair itself after a later version of LabVIEW is uninstalled If you uninstall LabVIEW 8.5 and a previous version of LabVIEW remains on the system, the previous version of LabVIEW might try to repair itself the next time you open it. The repair process might remove any patches you installed for that version of LabVIEW. Make sure to reinstall any patches you have on the system after the repair finishes. Workaround—Refer to KnowledgeBase 36ICL128 at ni.com for more information about correcting this problem. Date Added—09/01/2007 Return to top |
| 67931 4DJEJ200 |
Windows Explorer crash when opening LLB If you install LabVIEW and then install a previous version of LabVIEW on the same computer, Windows Explorer crashes if you use Windows Explorer to perform an operation on an LLB. Workaround—In the previous LabVIEW version installed, select Tools»Options, select Environment from the Category list, remove the checkmark from the Enable Windows Explorer for LLB files checkbox, and click the OK button. Display the same Environment Options page again, place a checkmark in the Enable Windows Explorer for LLB files checkbox, click the OK button, and restart the computer. Date Added—09/01/2007 Return to top |
| 114531 | LabVIEW Platform DVD installation fails at LabVIEW DSC installation While installing the LabVIEW DSC module, the installer prompts the user to reboot. After clicking OK to reboot, an error dialog pops up (but soon disappears because it's rebooting). When OS launches after rebooting, the installation does not continue. Workaround—Install MSI 3.1 (WindowsInstaller-KB893803-v2-x86.exe) from the \bin folder of DVD 1 before running the installer Date Added—07/11/2008 Return to top |
| LabVIEW Environment | |
| 46449 2JQ91R6I |
LabVIEW's Hierarchy Window does not show the labels of the VI's for print out When you print the VI Hierarchy window, LabVIEW does not print the VI labels. Workaround—N/A Date Added—09/01/2007 Return to top |
| 47212 3EIB4MS5 |
No prompt to add a comment in the revision history on close If you select the Prompt for a comment when the VI is closed option on the Revision History Properties page, LabVIEW does not prompt you to add a comment to the History window when you close the VI. Workaround—Select the Prompt for a comment when the VI is saved option on the Revision History Properties page Date Added—09/01/2007 Return to top |
| 47791 3MRDJ300 |
Subpalettes need to be context aware, i.e., need to show/hide when owning library is locked/unlocked LabVIEW does not correctly hide subpalette menus that belong to locked project libraries. Workaround—N/A Date Added—09/01/2007 Return to top |
| 52615 4BMANBJ1 |
Multi-frame structures do not switch frames on undo If you place a multi-frame structure (Event Structure, Case Structure, etc) on the block diagram, edit a frame in the structure, switch to a different structure and then press ctrl-z to undo the edit, LabVIEW does not switch to the frame that contains the change that you are undoing. Workaround—N/A Date Added—09/01/2007 Return to top |
| 36543 4039KEG8 |
Edit-time crashes when many modules, drivers, and toolkits are installed Edit-time crashes during various operations (right-click menu selection, VI save, moving a VI from one block diagram to another, building an application [executable], shared library, or source distribution, etc.) can result from LabVIEW's image table overflowing from large amounts of palette icons being loaded in memory due to many installed modules, drivers, and toolkits. In this scenario, may receive LabVIEW error log files reporting "You filled the image table" in image.cpp. Workaround—In Tools->Options->Controls/Functions Palettes, change the Palette Loading from "Load palettes in background" (default behavior) to "Load palettes when needed" and restart LabVIEW. This workaround does not work if you: 1. Perform a palette search. 2. Click "place me on diagram/front panel" from the LabVIEW Help. Date Added—10/08/2007 Return to top |
| 105509 | The "do not save automatic changes" setting does not affect libraries The "do not save automatic changes" options setting does not affect any type of library, including classes. Workaround—N/A Date Added—06/20/2008 Return to top |
| 117209 | Bundle by Name does not break VI when fields from the input cluster's type def are deleted Bundle by Name does not break VI when fields from the input cluster's typedef are deleted Workaround—Change the data type (numeric to string, string to numeric) of the cluster element to be deleted to force breakage at all references to that member. Repair the broken VIs and then remove the cluster element. Or you can delete the cluster element, save (keeping the control open), then mass compile (or whatever ensures all users of the typedef are resaved while the control is open). Date Added—07/08/2008 Return to top |
| 112746 | Quick Drop Shortcut does not work with English LabVIEW on a Chinese OS The default shortcut for Quick Drop does not work when English LabVIEW is installed on a Chinese OS. Workaround—Edit shortcuts, Use Chinese LabVIEW on a Chinese OS, or set the default language for non-Unicode programs to English(United States). Date Added—07/11/2008 Return to top |
| 42728 4FEAMCDP |
Disabling or enabling breakpoints on a single reentrant clone VI is impossible When setting or clearing a breakpoint on a diagram, it is possible to set and clear the breakpoints on an individual reentrant clone without changing the breakpoints on all the other clones of the same VI. However, when you try to disable or enable the breakpoint (a new feature in LabVIEW 8.6), the breakpoint is enabled or disabled on all clones and the original VI. Workaround—N/A Date Added—08/01/2008 Return to top |
| LabVIEW Object Oriented Programming | |
| 48855 3W6K2TMQ |
Undo on a private data control can leave you in a state where File»Apply Changes is needed but disabled Editing a private data control and then undoing the edits removes the documentation modification on the class. However, while the owning class is broken and expects you to apply the changes you made, the File»Apply Changes menu option is disabled on the private data control. Workaround—Select File»Save or File»Close to save or close the private data control. Date Added—09/01/2007 Return to top |
| 48913 3WGFQJ2K |
LabVIEW class save prompts sometimes come at incorrect times. If you right-click a control in the Project Explorer window, select Convert Contents of Control to Class from the shortcut menu, and then undo the conversion, LabVIEW might appear as if the class still exists and you might not be able to load a class of the same name as the control. Workaround—Save all files that reference the class you created from the control. This clears the backups of the files and allows the class to leave memory. Date Added—09/01/2007 Return to top |
| 49093 3XHF1O2K |
Running a dynamic dispatch VI as top-level and another VI that calls the dynamic at the same time can cause unexpected termination of running VIs When you run a VI by pressing its run arrow, that VI is referred to as the "top-level VI". A VI that is running top-level cannot be used as a subVI by another top-level VI. Normally if you run a VI top-level, any callers of that VI are broken until the VI finishes its execution. If you you run a dynamic dispatch VI as the top-level VI, callers of that VI are NOT broken. If you then try to run one of those callers, the dynamic dispatch VI might become idle. Eventually, any VIs using the class that the dynamic dispatch VI belongs to might break, or, in some cases, VIs may be in the strange situation of being editable while running. Workaround—N/A Date Added—09/01/2007 Return to top |
| 50616 45ME5NJ1 |
Cannot create an override member VI for both a child class and a grandchild class unless you first save the VI that contains the child class You cannot create a VI that overrides the functionality of a child class and then create another VI that overrides the functionality of a grandchild class unless you first save the VIs you want to override. Thus, if you right-click a LabVIEW class in the Project Explorer window and select New»VI for Override from the shortcut menu to create child:A.vi, you cannot select New»VI for Override for the grandchild class to create grandchild:A.vi until you save child:A.vi. This issue occurs because you cannot have two VIs in memory with the same filename that have never been saved. Workaround—Save the VI before you try to override any LabVIEW classes in that VI. Date Added—09/01/2007 Return to top |
| 52027 4A4GRP00 |
Cannot create override of password-protected VI unless you have the password You cannot create a VI to override an ancestor VI in a LabVIEW class if the VI you want to override is password-protected. Workaround—You do not have to use New>>VI for Override... to create an override VI. You can always create an override as follows: 1) create a new VI in the child class 2) save the VI with the same name as the VI in the parent class 3) drop controls/indicators on the child VI so that you make the connector pane match the parent VI 4) configure the child VI's VI Properties>>Execution page so that it matches the parent VI's settings. The automatic tool that does all this work for you can only operate on the parent VI if it can get access to edit (copy from, etc) the parent VI, which is why it requires the passowrd. The manual method for overriding is always available. Date Added—09/01/2007 Return to top |
| 54223 3Y18O59I |
The private data control can get into a permanent locked state when class loads into multiple application instances If you delete a control, indicator, or constant of a LabVIEW class, the backup object keeps the LabVIEW class loaded in that application instance. This backup object can cause a problem if the LabVIEW class is loaded in more than one application instance. Workaround—To edit the LabVIEW class, make sure the class is loaded in only one application instance. The backup object might be the only reason the LabVIEW class stays in memory in an application instance. To remove the backup object for the LabVIEW class, save or close the VI(s). Refer to KnowledgeBase 3Y18O59I at ni.com for more information about correcting this problem. Date Added—09/01/2007 Return to top |
| 110527 | Create Accessor dialog sometimes creates erroneous accessor VIs The Create Accessor dialog is unable to reliably create an accessor VI for a Class who's private data cluster contains an element with a name which begins or ends with whitespace. The bundle and unbundle nodes on the resulting accessor VI might have an incorrect element of the cluster selected. Workaround—Edit the resulting VI and correct the generated bundle or unbundle nodes. Date Added—06/20/2008 Return to top |
| 52753 4C08OCJ1 |
Locking all classes in inheritance hierarchy does not hide protected member VIs When you lock a class, all the private member VIs are hidden in the project tree. According to the documentation, if all the classes in a class hierarchy are locked then the protected member VIs should also be hidden. They are not. This is strictly a display issue. Protected VIs are protected and cannot be accessed except within the class and its descendant classes. Workaround—N/A Date Added—06/20/2008 Return to top |
| 110152 | Error Creating Override VI for Dynamic Dispatch VI with No Block Diagram If you remove the block diagram from a dynamic dispatch VI then try to use the shortcut option New-> VI for Override, the action will fail with error 1012. Workaround—Create the override VI manually. Date Added—07/11/2008 Return to top |
| 112847 | Changing LV class inheritance does not always fix broken wires A child class wire can always connect to a parent class terminal. You may connect a class to another class and get a broken wire, which makes you realize that you forgot to make the wire's class inherit from the terminal's class. So you go to the Class Properties dialog and change the wire's class to inherit from the terminal's class. This should be enough to fix the broken wire. In the case where the class wire is used but there are no controls/indicators/constants of the class anywhere on the VI, the wire will still be broken. In other words, the bug exists if the class is an output wire from one subVI call and an input wire to another subVI call. The inverse problem also exists: Alpha.VI is saved when class A inherits from class B. Now, while Alpha.vi is not in memory, change A to not inherit from B. Load Alpha.vi. It should load broken, but it does not. Forcing a recompile will cause the VI to break. Workaround—Any action that causes LabVIEW to re-evaluate the wire will work to fix this problem. Some options include a) unloading and reloading the broken VI b) deleting the broken wire and rewiring c) force recompiling the VI by holding down the ctrl key while clicking on the Run arrow. If you have many broken VIs that need to be fixed simultaneously, holding down shift+ctrl when clicking the run arrow will force all VIs in memory to re-evaluate. Date Added—08/01/2008 Return to top |
| 115897 | Cannot fix missing parent class by changing to inherit from LabVIEW Object If a class is missing its parent class, it is broken. The help for this error directs users to change the inheritance and suggests changing to inherit from LabVIEW Object. Changing the inheritance does fix the broken class, but only if you pick any class other than LabVIEW Object. Workaround—You have two possible workarounds: 1) Open the Class Properties dialog for the broken class. Change the broken class to inherit from another class that does exist. Hit "OK" to close the Class Properties dialog. Then change the inheritance again to inherit from LabVIEW Object. 2) You can open the broken class' .lvclass file in a text editor. Find this text: <Property Name="NI.LVClass.ParentClassLinkInfo" Type="Bin"> Delete that tag and everything that follows it until you find the matching </Property> tag. Save the text file. When you next load that class, it will be inheriting from LabVIEW Object. Note that this workaround will not work if the .lvclass file is password protected. Date Added—08/01/2008 Return to top |
| 117709 | Unbundling class private data control elements by name follows different rules than unbundling regular cluster elements The Unbundle By Name block diagram object behaves differently for unbundling private data control elements of a LabVIEW class versus unbundling elements of a cluster. If you are unbundling private data control elements by name and a field of the private data control is deleted, LabVIEW may sometimes incorrectly select a new element of the private data control, instead of breaking your VI and requiring you to manually select a new element. Workaround—N/A Date Added—08/01/2008 Return to top |
| 119962 | Doing find for "LabVIEW Object" crashes LabVIEW If you attempt to use Edit»Find and Replace... to search for all instances of LabVIEW Object (the ultimate ancestor class of all LabVIEW classes), the development system will crash. Workaround—The only known workaround is a programmatic solution -- writing a VI that opens control references to each control on another VI's front panel and tests if that control is an instance of LabVIEW Object. It can be tricky to write such a VI in versions 8.2 and 8.5. In LV 8.6, there is a VI to help you: [labview]\vi.lib\Utility\LVClass\Is This Control Of LabVIEW Object Class.vi A version of this VI for LV 8.5 may be found by searching the developer forums on ni.com. Date Added—08/01/2008 Return to top |
| 121514 | To More Specific node creates undesirable copies of LabVIEW class objects The To More Specific node makes a copy of the class when the operation is successful. This copy is unnecessary and has been identified as a source of performance problems. This bug exists in LV8.2 and later. For further details, please read: http://forums.lavag.org/LabVOOP-Performance-Issue-To-More-Specific-function-t11521.html Workaround—1) Whenever possible, LabVIEW class developers should avoid using the To More Specific node to do type testing -- use dynamic dispatch subVIs instead. That is good programming practice anyway, but this bug makes it even more important. 2) Any LabVIEW class developer who is writing a nested data type -- one where the child class includes an instance of the parent class in its private data control -- needs to be aware of potential performance problems if your data structure gets large, possibly changing to a different implementation of the data structure. These problems will persist until this bug is fixed in a future version of LabVIEW. Some nested data types, such as a simple linked list, may be implementable without using To More Specific by making all operations be dynamic dispatch VIs defined on the parent class, even operations that rightfully should only be called on the child class. The desired functionality is then placed on an override VI in the child class. This lets dynamic dispatching do the work of getting data from a parent class wire onto a child class wire instead of To More Specific. Date Added—08/01/2008 Return to top |
| 52574 4B8DH7J1 |
Race condition exists between loading a LabVIEW class and the Flattened String To Variant function When LabVIEW unflattens a LabVIEW variant, there is a race condition that might lead to a LabVIEW crash if the following conditions exist:
Workaround—In most cases, you can change your program architecture so that the unflattening of data is not happening in parallel to loading classes into memory. If you cannot make such a change, use semaphores to ensure that the loading code and the unflattening code do not execute simultaneously. See the LabVIEW Help for more information about the Semaphore palette. Also, there is no race condition against the Unflatten From String primitive. You may be able to rearchitect your code to use Unflatten From String instead. Date Added—08/01/2008 Return to top |
| LabVIEW Project | |
| 48100 3PCAD0J1 |
Save As»Substitute Copy affects all projects in memory, not just the one that does the Save As operation. If you have Alpha.vi loaded into two separate projects, these are two independent VIs in memory. If you do Save As»Rename then, LabVIEW correctly renames the VI in both projects since the actual source on disk has changed. However, if you do Save As»Substitute Copy, only one project should change. Workaround—Close any projects that you want to contain the original VI before performing the Save As»Substitute Copy operation. Date Added—09/01/2007 Return to top |
| 40906 4CN9KIG3 |
Disabling Autodeploy Shared Variable Setting Does Not Save in Auto Populating Folder with LabVIEW When you create a project in LabVIEW and add a Shared Variable and want to set the library to disable "Autodepoly Variables", the setting does not save if the library is in an auto-populating folder. Workaround—If you turn off autopopulate for the folder, you can disable the option to autodeploy variables and save it correctly. Date Added—09/13/2007 Return to top |
| 117582 | Private scope has no effect on XControls or StateCharts Marking an XControl or a StateChart as private inside an owning library will not prevent VIs outside the owning library from using that XControl or StateChart. Workaround—No known workaround. Date Added—08/01/2008 Return to top |
| MathScript | |
| 52985 4DJFLU00 |
Save for Previous on a VI with MathScript results in broken VI If you select File»Save for Previous Version and save a VI that contains a MathScript Node for LabVIEW 8.0, the VI is broken when you load it in LabVIEW 8.0. Workaround—To correct this problem, load the VI in LabVIEW 8.0 and then modify the script in the MathScript Node. For example, add and remove a space. Then click the block diagram outside of the MathScript Node. When you click the Run button, the VI runs correctly. Date Added—09/01/2007 Return to top |
| 91951 490EII2J |
MathScript realmax returns Inf instead of max pos real value. MathScript realmax function returns Inf instead of the maximum positive floating-point number. Workaround—N/A Date Added—09/01/2007 Return to top |
| 99336 | MathScript can not recognize variable with illegal character loaded from external data file You can use the load function to load data from external data files, such as .tdm or .tdms. MathScript loads each channel from the file as a variable where the name of the channel determines the name of the variable. However, MathScript cannot recognize variable if its name starts with underscore or contains illegal character, such as '-', even though the variable seems to be correctly loaded into MathScript. One exception is the space character. MathScript replaces all space characters in variable name with underscores when the variable is loaded. Workaround—Avoid using illegal characters for variable names in external data files. Date Added—07/09/2008 Return to top |
| 97533 | MathScript User Defined Functions (UDFs) that overload Control Design (CD) Functions that are also built-in MathScript Functions will not show up in the "help" command If CD is installed and the user also has a UDF with the same name as a Control Design function that is also a built-in function, then the UDF will not show up when the "help" command is run. For example, suppose the user has CD installed and also has a UDF called "norm.m". If they user enters "help norm" he would expect to see help for his function "norm.m", but he will only see the CD help, and there will be no mention of "norm.m". Workaround—Rename UDFs to avoid conflict. Date Added—07/11/2008 Return to top |
| 112426 | Import Script does not work for read-only files Import Script through right-clicking a MathScript node and selecting "Import" does not work for read-only files Workaround—N/A Date Added—08/01/2008 Return to top |
| 114532 | MathScript cannot create a subplot with multiple 3D graphs on it MathScript always creates a new plot window for 3D graphs, such as surf and mesh. Workaround—N/A Date Added—08/01/2008 Return to top |
| 99061 | MathScript Probe on a reentrant clone attaches to the original If you try to probe a MathScript node on a clone of a reentrant VI, the probe will actually attach to the original VI instead. Workaround—Turn off reentrant execution on the VI that contains the MathScript node before you attach the MathScript probe. Date Added—08/01/2008 Return to top |
| Menus | |
| 104160 | Right Click Wire: Delay in Appearance of ShortCut Menu After installing NI-VISA you may see a delay in the appearance of a shortcut menu after right-clicking a wire on the block diagram. Workaround—Mass compile LabVIEW\vi.lib\_probes. Date Added—07/11/2008 Return to top |
| 113591 | Read Palette VI returns blank item path if the item is not installed in the system When reading a palette, it returns empty path in "item path" for all items where the indicated path does not exist on disk. Workaround—Install all the products for the menu. This is impractical for some cases. Date Added—08/01/2008 Return to top |
| Miscellaneous | |
| 39908 4AIBSAFF |
When synchronous display is enabled, disconnecting and reconnecting to a LabVIEW Real-Time target performing image display in a loop causes the Real-Time target to hang If you enable synchronous display on an image display control and then update the control in a loop on a VI running on an Real-Time target, LabVIEW hangs after disconnecting and reconnecting to the target. This issue might occur when you want to run an application that can perform a headless operation, but you still want to perform image display in a loop. Workaround—Right-click the image display control and select Advanced»Synchronous Display from the shortcut menu to disable synchronous display. Date Added—09/01/2007 Return to top |
| 51185 47FGSQCS |
Cannot save VI as the same name as missing library member VI If a library contains a VI and the VI is missing, you should be able to save a VI as the same name as the missing VI in order to rebuild the missing VI. Currently, LabVIEW does not allow this. Workaround—Delete the item from the library, save the new VI as the same name as the missing VI and then move the VI into the library. Date Added—09/01/2007 Return to top |
| 52646 4BFH3J00 |
Timed Loops start returning error -800 before reaching the limit of 128 in memory Placing Timed Loops on the top-level block diagram, you can get up to 128 instances before receiving errors, but when the Timed Loops are in reentrant subVIs or instance VIs, the error happens before LabVIEW loads 128 instances. Workaround—If multiple VIs are in memory, close a few VIs and try again. You also can replace some Timed Loops with While Loops for emulation purposes. Date Added—09/01/2007 Return to top |
| 117216 | Instrument Driver Project Wizard reports a dependency error in report The Instrument Driver Project Wizard incorrectly reports the generated instrument driver has a dependency that is outside of driver and outside of vi.lib. Specifically, the instrument driver report includes the following in the generated report: "The driver is dependent on the following VIs that are not part of the driver or in vi.lib." However, no VI path is noted in the report. Users should ignore this dependency error if no VI path is listed in the report. It is a false error. Workaround—N/A Date Added—06/23/2008 Return to top |
| 99651 | LabVIEW crash in MemoryManager.cpp line 406 with MixedSignalGraph strict Value property LabVIEW crashes if you create a Value property node from a Mixed Signal Graph reference, unbundle the value, and then change the data in the cluster. Workaround—Create the Value property node from the graph instead of the reference to the graph. Date Added—07/08/2008 Return to top |
| 44355 4HGA9JBK |
Timed-Sequence iteration duration terminal does not work The Iteration Duration output terminal on Timed-Sequence structures no longer functions correctly. Workaround—Use the Global End and Global Start time to calculate the total duration of the structure. Date Added—07/09/2008 Return to top |
| 116843 | Expected End Calculation for Timed Loop Iteration is incorrect when Deadline is used The current calculation for Expected End for the Previous Iteraction is Actual Start + Deadline but the correct calculation should be Actual start + Deadline - 1 Workaround—Subtract one from the Expected End output before using it. Date Added—07/10/2008 Return to top |
| 117557 | Cannot Edit I/O Alias Properties after deleting the bound I/O Variable If the I/O Variable that is bound to the I/O Alias is deleted, then it will not be possible to edit or view the Properties of the I/O Alias. Opening the Properties dialog box of the I/O Alias will result in an error. Workaround—Add the I/O variables back to the project to access the I/O Alias Properties. Date Added—07/10/2008 Return to top |
| 120556 | Constant-folded case structure tunnel coerces to non-folded type in LabVIEW 8.5 but not in previous versions If you have a case structure wired with a constant and including a tunnel, and you have two differing, but coerceable, types wired to the tunnel, the type of the tunnel is now (LabVIEW 8.5 and later) dependent on which case has been folded. In LabVIEW 8.2 and prior, LabVIEW coerces the value based on rules for the type. Among other things, this change means that when you upgrade an application from older versions, it may have broken wires or changes in data types. Workaround—Wire a control to the case structure instead of a constant to prevent the constant folding. Date Added—07/22/2008 Return to top |
| Operating System Specific | |
| 67694 4DJFAN00 |
With Windows XP Service Pack 2 or Windows Vista, a Security Alert appears when launching LabVIEW or the NI Example Finder If you have Windows XP Service Pack 2 installed or use Windows Vista, a Security Alert dialog box appears when you launch LabVIEW or the NI Example Finder for the first time. If you select the Keep blocking this program option, the LabVIEW VI Server, LabVIEW Web Server, and any server written in LabVIEW cannot accept incoming connections from a remote computer. Workaround—Select the Unblock this program, despite the security risk option to configure your computer to launch LabVIEW without any changes in functionality. Refer to KnowledgeBase 3HUD6PUW at ni.com for more information about correcting this problem. Date Added—09/01/2007 Return to top |
| 67879 4DJFNG00 |
The LabVIEW installation process enables write permissions for any folders, files, and registry keys that LabVIEW might write to during normal operation. For compatibility reasons, the LabVIEW installation process enables write permissions for any folders, files, and registry keys that LabVIEW might write to during normal operation. This may have some effect on Windows Vista users. Workaround—N/A Date Added—09/01/2007 Return to top |
| 68072 4DJF8700 |
The NI Publish-Subscribe Protocol (NI-PSP) incompatible with the Windows XP Service Pack 2 firewall The NI Publish-Subscribe Protocol (NI-PSP) networking technology is incompatible with the Windows XP Service Pack 2 firewall. You must disable this firewall for networking to function correctly. Workaround—Refer to KnowledgeBase 37H7JBQA at ni.com for more information about the firewall. Date Added—09/01/2007 Return to top |
| 91250 453BD7Q6 |
LabVIEW crashes on Japanese Vista if system locale is set to a Western European codepage If you have a user name that uses Japanese characters and change the system locale to something other than Japanese, LabVIEW crashes. Workaround—Make sure your locale and user name match. Date Added—09/01/2007 Return to top |
| 114264 | WebServer does not handle html file whose name contains Japanese characters. If an html file is created from VI which is under a project, "project name»Target Name»VI name.html" will be the default html file name. Most commonly, [Target Name] will be "My computer" in Japanese for any users using Japanese OS. If these characters are included in the html file name, you cannot open the html file through the LabVIEW Web Server. Note: Not all Japanese characters cause problems. Workaround—N/A Date Added—08/01/2008 Return to top |
| Performance | |
| 43026 4FIIUH7N |
Timed Structures May Leak Memory The Timed Sequence Structure uses a DLL which is loaded when a VI using the timed structure is loaded in memory. Loading and unloading this DLL causes a small memory leak. It is unlikely that your application would be loading and unloading this DLL multiple times. Workaround—In order to work around this problem, you must keep the DLL used by the Timed Structure in memory. To do this, simply have a VI loaded in memory that uses a Timed Sequence Structure. You could do this by having a 'dummy' sub-VI in your top-level VI which just has one instance of a Timed Sequence Structure that does nothing but keep the DLL in memory. Date Added—06/20/2008 Return to top |
| Remote Panels | |
| 46442 2BCDF100 |
Remote Panel not correctly displaying hidden/disabled controls when server is a built app. Clients viewing a front panel remotely might see different behavior depending on whether the front panel they are connecting to is from a built application. Specifically, if the front panel is from a built application, any programmatic changes to the front panel made before the client connects to the front panel are not reflected on the client computer. For example, if a Property Node changes a caption on a control before a client connects to that front panel, the client will see the original caption of the control, not the changed caption. Workaround—Refer to the National Instruments KB 3K7COT23 for more information about this issue and workarounds. Date Added—09/01/2007 Return to top |
| 50165 4367OV4I |
VI in web browser with top-level window or dialog window style does not draw. If you create a VI, select Top-level application window or Dialog options from the Window Appearance page in the VI Properties dialog box, and publish the VI to the web, when you view the VI, it uses the default window style instead of the style you selected. This issue was formerly documented as issue 51263/47MA31QO. Workaround—Do not set the window style of a VI to top-level or dialog if you want to publish the VI to the Web. Date Added—09/01/2007 Return to top |
| 97181 | On a Mac, a VI that writes waveform data to a chart on the Web Server crashes the Web browser when accessed from a PC When posting a VI that writes waveform data to a chart inside a loop on the Web Server for remote front panels on a Mac, accessing the remote front panel from a PC may crash the Web browser. Workaround—Use graphs instead of charts. If chart functionality is necessary, you can programmatically create a history of data that gets plotted to the graph on each plot. Date Added—07/08/2008 Return to top |
| Shared Variables | |
| 48195 3Q9DN1ZU |
Deployment fails for all Variables in a Library if one Variable has a bad binding LabVIEW fails to deploy all shared variables in a library if one shared variable has an invalid binding. Workaround—To correct this problem, either delete the shared variable that has an invalid binding or unbind the shared variable. Date Added—09/01/2007 Return to top |
| 48349 3R8EFNKY |
VarClient on cFP reports "variable does not exist" if the variable is published by a host that has two ethernet adapters Network-published shared variables do not function properly if multiple network adapters are enabled on the same computer. Workaround—You can bind variable communication to a specific network adapter. This will allow variable communication to function normally on the bound adapter. It is not currently possible to perform shared variable communication on two network adapters simultaneously. For instructions on binding variable communication to a network adapter see KB 3WK9NH9A: Deploying Shared Variables to a Specific Network Card. Date Added—09/01/2007 Return to top |
| 88869 3KAEOHC3 |
Private variables are accessible outside their Library You can read from and write to private single-process shared variables. Workaround—N/A Date Added—09/01/2007 Return to top |
| Source Code Control | |
| 107802 | When working with LabVIEW Libraries and their VIs outside of a LabVIEW Project environment, LabVIEW may display incorrect Source Code Control status for files. When working with LabVIEW Libraries and their VIs outside of a LabVIEW Project environment, LabVIEW may display incorrect Source Code Control status for files. For example, files may be checked out but LabVIEW will not reflect this. This problem also applies to LabVIEW XControls, Classes, and Statecharts Workaround—Work with your files inside of a LabVIEW project if you are using Source Code Control. Date Added—08/01/2008 Return to top |
| Upgrade | |
| 116237 | The Method Save.Instrument Returns Error 1357 The behavior of the method Save.Instrument has changed when "Save a Copy" is true and the Path to Saved File is the path that the VI reference is loaded from. In LabVIEW 8.5 and previous, you could overwrite the existing VI when Save a Copy was true. In LabVIEW 8.6 this now returns error 1357. Workaround—This behavior was changed |