Leaderboard

Short answer: Yes. Long answer: My reuse code covers relatively large units of functionality. I don't deploy anything smaller than a class and most of my reuse modules are multiple classes contained in an lvlib. I don't bother keeping a set of independent utility vis as part of my reuse library. If there's a handy utility vi I could use from a different project, I'll create a new vi in the current project and copy the code. I never have source vis from a separate, independent project show up anywhere in my current project's project window. Your problem is a little bit of a special case in that the two projects aren't completely independent. I have a similar situation right now where I have been writing a helper app to create calibration data that will be used in our main application. In this case I created a folder for my sub-project in the scc tree of our main app, started a new project there, and including the new project in the main project. My CalFileEditor links directly to the other code, but since it's all in the same scc node the chances of conflicting changes is lessened. I've also tried to insert abstraction layers to protect the CalFileEditor from changes to the main app source code. (See below for one example.) If the code I need somewhere else is expected to be generally reusable, I'll extract it, generalize it, and deploy it to my reuse library. More specific reusable code stays in the projects. If you're going to have applications with overlapping functionality and you want to reuse source code, the single most important thing is to make sure you manage the dependencies of your reusable code. Nothing's worse than dropping in a class you think is reusable, only to see it import another 2000 vis from an application written last year. Assuming you've done that correctly and you expect there to be more apps to follow, I would probably create a single parent directory containing directories for each of the individual applications that make up the system. I'd also add a Shared directory for code used by multiple apps. When you find something in one app you want to use in another app, extract it from that project directory and put it in your Shared directory. (Be careful not to break the links in your original app!) Then, once you've moved the code to the shared directory, remove it from your original app's project to indicate that app no longer "owns" that code. Better to recognize the potential trouble now than after the damage is done. Nope, I don't use passwords at all. I do lock the libraries, but no passwords. Nothing I distribute to users contains confidential IP they are not allowed to see. If a user wants to get in and muck around with the code... that's on them. I can't protect them from their own stupidity. If the time comes when I do need to use passwords, I would likely start with random passwords. If someone needs to see a block diagram I can always rebuild that module with a specific password for that user. Lucky dog cat!

You can deal with the alignment problems by changing the format to a 1D array of clusters, where each element in the cluster is a column. The main problem with this is detecting which row received the event. I would suggest using a value change event and comparing the NewVal and OldVal terminals, like this: (inside is a cluster to array primitive).

Skip the UDL file altogether and wire a connection string directly into the Open Connection function.

I don't have any specific numbers but I can state that trees con be rather slow for updating when there are a large number of elements. The way to improve this performance is to keep a separate 1D array which represents the tree and operate in this when you need to make changes. Use the property node for the tree to update the entire tree in one shot. Using this approach I have had trees with over 10000 elements in it and it updated fairly quickly. Certainly it was fast enough that it didn't cause user angst when working with it.