George,

I understand your frustration, and came up with a solution a long time ago (LV 3.1 
anyone??) that works for me.  Unfortunately it does require a little discipline at the 
start and during the development of a project.  I ALWAYS keep my projects in their own 
folders within the LV subdirectory <<project>>.  I regularly compile and use the "save 
with options" to save ALL, including what I refer to as "native" vi's, (this really 
pays dividends when modifying older projects) - a word of caution for those not too 
familiar with some of the "features" of this tool, double check you are NOT removing 
diagrams during this save, and you also have to step through the options in a 
particular order to be able to get the configuration you want. If I needed to modify 
any of the "native" vi's, I would rename them "My_native-name.vi", keeping the 
original name in there helps a lot.  As focal/support point for a team of LV 
programmers, I would insist they all organised their work in this fashion as it helped 
in being able to pick up other people's work.  This may sound like creating an 
overhead in terms of file size, but in these days being able to archive to CD (ahh 
those Scooby Snack piles of floppies.....)it is not a problem.
Hope this offering is of some help.


David Hooper
Engineer, Instrumentation & Plant Automation
Shell Global Solutions (UK)
Cheshire Innovation Park, P.O. Box 1, Chester CH1 3SH, United Kingdom

Office: +44(0)151-373 5443 Fax: 5843
Mobile: +44(0)7776 464611
Email: [EMAIL PROTECTED]
Internet: www.shellglobalsolutions.com

Subject: Confounded and Ranting
From: "George Gatling (Contractor)" <[EMAIL PROTECTED]>
Date: Fri, 27 Feb 2004 21:09:59 -0500

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?

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!!

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.  So I have to play tricks like 
temporarily renaming folders or mucking around with the search 
paths.  Inevitable I wind up having to rename all of the files with some 
clever prefix, but when there are more than say two files it really starts 
to irk me.  Because it is not enough to rename them in windows... then you 
have to go around replacing everything... and there other choice is no 
better.. clicking save as is just as much wear on my poor mouse and always 
seems to risk getting the old app pointing at the new app.  It is not even 
safe to close everything except labview because I have noticed that 
occasionally something is still hanging around.  It won't be in the 
hierarchy window, but the app builder sure seems to find it.  No doubt this 
has nailed me in the past too.

Perhaps I am just an idiot and there really is a clear explanation of how 
to control what vi's are pointing to what that I just don't know.  That 
would be a nice case, because I don't mind being humbled every now and 
then, especially when that helps get work done :))

But seriously,  what is going on with the linking and HOW did labview start 
pointing to half of an app in a temp folder?

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.



George Gatling
Applied Technology Division, SFA Inc.
Space Physics Simulation Chamber
US Naval Research Laboratory
202-404-5405 (phone)
202-767-3553 (fax)

If trees could scream, would we be so cavalier about cutting them down?
We might, if they screamed all the time, for no good reason.  --Jack Handy  


Reply via email to