> But seriously, what is going on with the linking and HOW did labview start > pointing to half of an app in a temp folder? >
I stinks when this happens, and I'm afraid I can't tell you why it definitely found VIs in your temp path. First, let me review the way LV loads VIs, then I'll make a few guesses and some suggestions. You are loading a VI A from somewhere on disk w:\g\h\j and it references B and C. The first place LV looks is ... ... in memory. LV can only load a VI with a given name once, and in trying to load a VI named A, it cannot do it if a VI named A is already in memory, even if the A in memory comes from path X:\. For a long time, this was a silent failure, but as of 6i or so, LV started putting up an informative dialog telling you that the thing you think you loaded, isn't really what you loaded since something else was already in memory. Sometimes this is what you wanted, othertimes it is the beginning of the nightmare. So if you get those dialogs, READ them. If it sounds scary, like a cross-linkage, kick everything out of memory and load it again. If there isn't already an A.vi in memory, the next place LV looks is ... ... where you told it to, w:\g\h\j for a file named A.vi. If the file is a VI, it loads it into memory and looks for subVIs to load. In this case it needs to load B.vi and C.vi. A will have a relative path to B and C. It will take the path to A and build paths to B and C and go through this process again, starting with ... in memory. LV never searches for user directed Opens or VI server top level VIs, but with subVIs, it will do one more thing before giving up. If B and C aren't in memory, and if the path built using the relative path doesn't yield a subVI, then it will resort to searching. By default, the search path is pretty benign. It says to look beneath the top level VI. Then it says to look anyplace that it has already found a VI -- sort of a shortcut cache -- but this also includes places that you showed LV. This means you don't have to keep showing it that you moved everything to y:\. The next place is vi.lib. Why vi.lib, because that is our stuff anyway, and when groups within NI change their mind and rename folders, we wanted an easy way to not have every customer call us looking for the VIs. Next is user.lib, and instr.lib, assuming that if is good enough for our library, it is good enough for those that the user and company get to define. If you change your search directory, you need to be aware, that you are telling LV that it is OK to load subVIs from there whenever it doesn't find them in the expected place. So guess number one is that you saved some VI in the temp directory, as a temporary, forgot to kick it out of memory, then loaded the rest of your app, which referenced the name of the thing in temp. When you save your app, it will need to save since it needs new paths to its subVIs, it will now look there, in temp for them. By the way, a nast place for things to hang around in memory is the clipboard. Unfortunately, if the last thing you did was copy the subVI call to the thing in temp, kicking the callers out of memory isn't enough, the subVI call is still on the clipboard waiting to be pasted somewhere, but this feature means that it is in memory. Guess number two is that your search path includes something like c:\* or c:\temp. These mean that LV will ask you to find things for it less often, but you may not like where it finds them. Finally, I've seen a number of utilities that will print out the location of all subVIs in a report. If you don't have such a tool, the hierarchy window, possibly with complete help window will do, but a two column listbox report is ideal. You can run this occasionally to verify that things are coming from expected drives and directories. I think this is a very important topic, and if you have further questions or gripes, it is a good time to cover them. Might even have something to do with what I'm working on. Greg McKaskle
