Leaderboard

Well partly yes, i do have an issues with this. However, i also have an issue with global dependencies and honestly there may not be away around that based on how labview was designed. I don't have as much experience with Labview as a lot of people here so i'm sure there are lots of use cases where it might be needed. However, i think there are two types of labview "packages". One would be your IDE extensions such as the G-code manager that you linked. These types of packages work well with VIPM and are good for extending the functionality of the labview IDE. However, i think project specific dependencies, such as OpenG, should live in the subfolder of the project. This would basically mean having a separate copy of OpenG for every project you are working on. Personally i think this makes sharing code a lot easier than running a VIPC file every time you change projects. It compartmentalizes project specific dependencies away from the IDE/Program Files location and into a specific place. It also prevents one project from touching the dependencies of another. So there may be more downsides than not, i'm not sure, but i think its a better approach than global dependencies.

No can do. Once you create a Signal object it will forever be a Signal object. You can't downcast a parent object into a child object--it opens the door to too many problems. (Here's a post from AQ with some more details.) I can't say this is the best procedure, but it's how I've solved the problem in the past. Create a child class with the attributes you want. The parent data in the child class will all be set to the default values. Then copy the parent data from the existing parent object into the new child object's parent data. I've attached an example using 2010. DowncastingObjects.zip