Leaderboard

I've never done it that way, for shared dependencies I've always made packages and installed them into vi.lib, which eliminates the problem. I don't think there is an easy fix. The fix I can think of is that there are several steps to the sample project: a dialog is displayed, then it copies the sample project into a new location, then it runs any post-copy scripting code. My suggestion would be to ask your users, in the dialog, where their 'root' project directory is. You can then through either the default value vi, or that same VI loaded up in a more appropriate application context (you may need the super secret ini key turned on to find the right one), get the ancestor classes loaded in from the appropriate path. Once they are loaded, and you reach the copy part of the script, labview should accept that they are the right ones (it might fuss that dependencies were found in the wrong location, but it should work). Another route would be to just make a tools menu item which replicates the sample project script, but with your particular variations like asking the user for their main directory -- that would be my workaround if labview does weird stuff with application contexts when its copying the project over. I don't know the exact procedure.

Just so everyone is clear: Using the Not A Refnum function to decide to create a refnum is ok because the zero refnum cannot be destroyed/released in a parallel thread. But since the primitive does the extra work of validating the refnum, you take a performance hit on the cases that are going to succeed. Using the Not A Refnum function to decide to do an action or not is a race condition because a parallel thread could be destroying that refnum in between the test and the action. If you need to actually do an operation, do one of these: If you need the combined behavior of "if the refnum is bad, allocate it, and do some operation on it", then do this: What is an acceptable use case for the Not A Refnum primitive? When you're evaluating the status of one refnum before taking an action on another refnum! Or if you're just displaying information in a Custom Probe. Or if you have absolutely nothing happening in parallel (in which case, you might reconsider your use of references anyway). (For advanced users who suggest the use of semaphores to protect the access, that counts only as an OK usage because you still have a performance hit of unlocking and locking the refnum twice.) If you ever are tempted to file a bug report that the LabVIEW queue functions are broken, please check your use of Not A Refnum first. I guarantee I will when the bug report gets to me. 🙂 And, for the record, all of the above also applies to using "Get Queue Status" and "Get Notifier Status" functions. And any other similar "is this refnum still valid" functions that you are using to make decisions in code.