‎09-15-2005 12:54 PM
‎09-15-2005 01:08 PM
ANy VI that you don't explicitely save in the a new location will continue to load from the old location as specified in the VI. You could close LabVIEW and rename the old folder. Now it will ask you to find all missing VIs. Once everything is loaded, do a "save all" to permanently update the new paths.
What I usually do:
Once you have a final version, you should do a "save with options".
Select "save as development distribution" and select a new empty folder as target. It will contain all VIs used in the project. Close everything, then run it from the new location.
‎09-15-2005 01:22 PM
Thanks for the info.....but I've got one more question for you. I'm using LabVIEW Ver 7.0 and could you tell me where I might find the "save as development distribution" feature?
tks
‎09-15-2005 01:27 PM
You first need to select "(menu)...File...Save with options..".
In the following dialog, select "Development Distribution".
See how far you get... 🙂
‎09-16-2005 08:32 AM
Thanks.....I sorta had a brain fart. I forgot that the pull-down menus on the toolbars dont always display all available selections....this was evident by the appearance of the double-down arrow at the bottom of the pull down menu.
I think I've got it now.....thanks alot for your help and see ya
‎09-16-2005 09:02 AM
LabVIEW, C'est LabVIEW
‎09-16-2005 09:44 AM
@TCjr wrote:
... I forgot that the pull-down menus on the toolbars dont always display all available selections....
‎09-16-2005 12:00 PM
Just chiming in briefly to say that it IS possible to simply copy a vi hierarchy from one place to another. This is the technique I've used as a poor-man's (or more accurately, lazy-man's) version control method. Here's what I do:
1. My top-level vi (or vi's) reside in a particular folder. My sub-vi's are all located in sub-folders underneath the main folder.
2. KEY STEP! When my editing is done and I'm sure I've got the overall version that I want to backup / move, I completely exit LabVIEW.
3. Then I use Windows Explorer to copy the entire top-level folder (including all sub-folders) and paste it wherever I choose. (When copying to a backup archive, I typically rename the top-level folder to include the date.)
4. Inside the top-level vi, paths to all sub-vi's are stored as relative paths. So if you now open the top-level vi from the new location, it will automatically be linked to the sub-vi's from the same new location.
Of course, as usual, you also wouldn't go wrong following altenbach's advice.
-Kevin P.
‎09-16-2005 12:26 PM
‎09-17-2005 11:54 AM
Adding to all of the previous.
I use a "Tree.vi" to make sure all the VI's in an application are in memory while I am editing.
The Tree VI does not do anything and never runs. It just contains the top level VI's used by the app. Dynamically called and templates are included so that I can use the "Save with options techniques mentioned below.
By working with the Tree.vi open I can tell of any of my edits breal any of the other VI's that I may not notice because they are called dynamically.
In larger app's my top level tree generally consists of a bunch of sub-system trees. The multi-level tree approach lets me easy re-use parts of one application in another. All I have to do is find the tree that contains all of the parts I will re-use and do a Save with....
The Tree also helps when working teams of devlopers. If one developer makes a change that forces another VI to recompile, when the Tree is closed LV will ask if the affected VI's should be changed. As long as the devlopers do NOT hit "save all" they can let the rest of the team know about the need to re-save VI's.
Ben