Leaderboard

As a word of warning to anyone reading this, be aware of the issue of Root Loop blocking by things such as the User opening a menu. Safety-critical code must never be dependent on Root-Loop blocking functions, such as “Open VI ref” or “Run VI”; the User can open a menu then walk away. If in doubt, test it by opening a menu and leaving it open just before your critical code executes. If it doesn’t execute until you dismiss the menu then you have the problem. The simplest fix is to open necessary references once at the start of the program, and use the ACBR node instead of the “Run VI” method.

The second is not really a bug. The End of Line constant on Windows is rn while when entering multiple lines in a LabVIEW string LabVIEW uses a single n only, except one explicitly enters the rn sequence. So the rn does not occur and therefore won't cause the string to be split in multiple elements. Enclosed is a first attempt at fixing the "ignore duplicate delimiters?=TRUE" case. String to 1D Array.vi

AQ's workaround for a deployed application (always my situation) is to add the .lvclass files to specific paths inside the built EXE, then provide a path to the class file using the Application Path primitive and a relative path inside the EXE. It doesn't actually pull an instance of the object from the application's memory space using the qualified name, but it's a workable approach since the EXE path can be obtained using a prim. To specify the location of the .lvclass file inside the EXE, add it to the "Always Included" list in the build spec, then create a "Destination" for it with the full path. For XYZ.lvclass, an example Destination Path would be C:\build\MyApp.exe\XYZ\. When you want to load an object of XYZ at run time, you provide the path C:\build\MyApp.exe\XYZ\XYZ.lvclass AQ told me that all the classes to be loaded need to be either inside the EXE or outside it; they can't be mixed. I didn't test that assertion b/c all my classes will be shipped in the built EXE.