10-13-2005 01:58 PM - edited 10-13-2005 01:58 PM
Message Edited by TonyO on 10-13-2005 02:02 PM
10-13-2005 02:05 PM
10-13-2005 02:15 PM
I agree with altenbach for utility type VIs and common drivers. I use source code control for them, but have them set for a shadow folder in my user.lib, puts them at my finger tips. If other VIs are required to cross projects, I create symbolic links within the source code control to insure that updates to one are replicated through to other projects, but crosslinking is an issue. I have to insure that all subVIs to the one that needs to replicated are also symbolically linked and relative paths stay the same. Currently a very manual process.
If only I had time to work on my project builder idea....
10-13-2005 02:25 PM
User.lib as mentioned by the others is the way to go if you have no issues reagarding sharing the contents of user.lib across multiple machines. The complications I have seen with this is that if I move an application to my customer's machine and some of the VI's were stored in user.lib the application will not find them unless I thought ahead and pulled out the parts the app needs. I also do not want to give away my entire re-use library everytime I include one of the containded functions.
If you just want to pull out elements from your collection then templates can be of some use.
If you need to selectively pull out parts of your archieve for use when required, then a "Tree.VI" can help. A Tree.VI is a VI that contains all of the top level and dynamixally loaded VI's used by the function to operate correctly. By opening the Tree.VI and doing a "Save with options"... single prompt preserve hiarchy... the requred VI's are copied to the new location and saved with the relative paths adjusted to point at the new location. This takes care of the cross linking issues.
Ben