Leaderboard

View File Hooovahh Array VIMs Here is the Hooovahh Array VIMs. This initial release contains 14 VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques. In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette. Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels. And a few functions have added performance based on other inputs. For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted. The Filter 1D array can also be more efficient if the input is known to not contain any duplicates. Because these packages contain VIMs, they require LabVIEW 2017 or newer. Having these functions be VIMs mean all functions work with various array data types. Included functions are: Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort Submitter hooovahh Submitted 10/11/2017 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)  

A Windows Restore revision fixed my initial issue, whatever it was. Then I got to work debugging a second issue in building, which turned out to be the very VIM issue you are talking about. I was able to identify a workaround (posted in your link), which is to delete the "Help path" to the extended documentation. If your VIM don't have extended documentation, then I think you are OK. The bug involves VIMs, extended help, and at least one other issue that I could not identify (builds of simple exes don't exhibit the issue).

The icon for user.lib\_OpenG.lib\string\string.llb\Multi-line String to Array__ogtk.vi and ...2__ogtk.vi contain a down arrow, slash, then left arrow. The down arrow represents a new line (or line feed character LF) and the left arrow a carriage return (CR). That the LF is in the upper left and the CR in the lower right implies that its end-of-line (EOL) is an LF followed by a CR. However, a string into it containing LFCR line endings is output with double the number of elements than it should, separate ones for the LF and the CR, such that every other element is an empty string for what it between them. In other words, it requires an EOL as a CR followed by an LF (CRLF) but the icon advertises LFCR. I happen to know of a hardware manufacturer that outputs LFCR and this VI did not work even thought the icon looked like it would.