"George Gatling (Contractor)" <[EMAIL PROTECTED]> wrote: >I am happily working my way through my current project when I suddenly >realize about half of my application is in C:\Documents and Settings\...\Temp\ > >I have no idea how long I have been editing files in a garbage temp folder, >not to mention which ones are linked to the temp files vs the real files. >GRRR!! Has anyone seen this behavior before? How does an entire app get >copied to temp AND then why does LabVIEW link half to temp and half to real?
What has happened here is that your target drive was full at some point. LabVIEW saves its files into the temp directory before moving them to the real target to prevent corruption of at least the original file due to memory, system or disk space problems. If the target drive is full LabVIEW aborts the save operation but the files saved to the temp directory stay and if you later save the application again, the current temp copies can get the actual linked ones. >This is a problem in itself, but also underscores the absolute need for >some sort of project environment. I have been working with LabVIEW for a >long time now and I still find myself baffled by labviews sneaky way of >linking things together. I realize that it is not easy, every function >also being its own file, but come on! Surely it would have been time well >spent to clean up the linking situation rather than create a bunch of code >cryptifing express vis!! A project environment does not remedy the linking issue at hand at all. The issue really is that LabVIEW uses dynamic linking, which has a lot of advantages. The disadvantage is that if you are not careful you get into a version mess better known under Windows as DLL hell. The solution MS has come up finally to resolve that issue is to actually have each application install and use its own DLL, as the application root directory is the first searched at (almost) all times (no rule without exception of course). The underlying Windows loader however will still pick up any DLL with the same name it can find, if the application directory does not contain the desired DLL. LabVIEWs approach is not that different and in fact quite well documented. It stores the path to the VI in the caller, a relative path if it is on the same volume and an absolute path if the volumes are different. When loading a VI all its callees are first searched at that stored location and if not found LabVIEW will start to work through its search paths configured in "Tools->Options". If not found you are given the chance to find it yourself and if you are not careful in which directory you start in the File Dialog you may actually point LabVIEW to the wrong version yourself. All complicated and prone to get into errors? Yes but any other approach seems even more inpractical to me. The thing I always do, often in between for bigger projects, but always before releasing, is using the Top Level VI which contains all the main and dynamic VIs of the project, go to Save with Options, Save entire hierarchy, New location - single prompt - preserve hierarchy, don't save VI.Lib and saving it into a new and empty folder. You immediately see if you reference VIs outside of the expected project directory, and also get rid of all cruft VIs not used anymore in your project. Then remedying any problems is basically making the undesired VIs unavailable to LabVIEW by temporarily moving or renaming the top level hirarchy directory of those undesired VIs and reloading the project again through the Top Level VI. Now LabVIEW will prompt you for the files not found, so just point it to their location or better yet adjust the search path in Tools->Options to let LabVIEW find the real good files. >So often I have had two very similar projects and I just wanted to copy the >whole code pile and start from there. But nearly EVERY time I do that I >wind up accidentally editing one or two files in the old app because not >all of the copied files linked correctly. Either your project is not located in one single hierarchy of files so that you copy two different top level directories and LabVIEW remembering the location of the original files will refer for files from the other than Main VI directory hierarchy to the original ones again. Or you happen to have those VIs in the clipboard so that LabVIEW picks them still in memory (and their disk location, as it needs to know how to save VIs back to disk on change) >Of course I should have expected all of this because it is 9pm on a Friday >and nearly all software bugs (aka features) seem to be able to sense this. Hmm interesting theory, and as applications get more and more complex some sort of intelligence could maybe develop ;-) But my experience is more that I do those stupid things more likely on such a moment than early in the morning when I'm still fresh. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
