Leaderboard

they're called hash marks and indicate where LabVIEW compiler will optimize and fold it into constant code. you hide these by changing your LabVIEW settings in the 'block diagram' page see online help : https://www.ni.com/docs/en-US/bundle/labview/page/block-diagram-objects.html bonus link : https://forums.ni.com/t5/The-Daily-CLAD/LabVIEW-Compiler-Optimizations/ba-p/3482600

As far as I know, a .NET dll in LV is loaded on the 1st call to one of its functions, usually a constructor.

for what it is worth, we do this... I have a shallow-ish hierachacy somthing like ths: actor <-- device <-- type_of_device <-- concrete_implementation We have some scipting code to help us make a new instance of type_of_device <-- concrete_implementation I have a template with the last two in a .lvlib, and we clone them as needed to two brand new classes. To further complicate, our stuff is in PPLs.

Hi Richard, I was referring to the Save a Copy on a LVLIB that contains classes A and A1, instead of saving individual classes sequentially. You'd start with Template.lvlib:A.lvclass * Template.lvlib:A1.lvclass, and end up with Clone.lvlib:A.lvclass & Clone.lvlib:A1.lvclass Your new clone lvlib will maintain the linkage within its own namespace. It then becomes a renaming operation for the Clone.lvlib:AX.lvclass to Clone.lvlib:BX.lvclass This only work if your template has all dependent classes in the same lvlib, hence why I called that a "special case". Your solution is more generic. Even when I don't want the classes to end up in the same lvlib, I prefer to extract them after they have been cloned...