Averting LabVIEW auto update of prior code, is this how?

[billko]

---

@rolfk wrote:

---

@3d0g wrote:

"I do sometimes enable the View File Path option to verify in the project view that the physical file hierarchy matches (often not strictly) the logical project view, especially when I have to maintain a project that someone else wrote. "

Back to the old fashioned way.

I don't understand "View File Path" option.  I don't think you mean the project's "Files" tab I was referencing.

---

This is the Files view (which I never use, haven't even looked at that in any project in years).

And this is the project view (Items View) with Project->Show Item Paths enabled.

I'm not really using those paths all the time, but for projects that I haven't created myself it can be helpful to be able to control if files belong to some group based on the directory they are in (and then fixing the mess) so it is more consistent.

So unless you were talking about something else than the first image, I'm standing firm on my statement, that the Files view is not necessary at all to be able to maintain a clean project files structure. And I'm not arguing this with you as you like to want to. If you feel different, that is totally fine with me. Do whatever you feel more comfortable with. But you asked for our opinion and kind of chided on Santosh (if not even tried to belittle him) for not taking your bait about who agrees or disagrees with you.

---

I enable "Show item paths" because it makes it painfully obvious to me if I placed something in a library but in the wrong physical location.  All the files there will have the same path except for that one, and it sticks out like a sore thumb.

[altenbach]

---

@3d0g wrote:

"inline programming world"

 ...I need to read that linked LabVIEW compiler doc. 

---

Yes, please do before continuing this discussion!!! 

(For a reasonable discussion, your brain cannot be all output, there needs to be some input. 😄 )

"Inlining" has a very special meaning in LabVIEW, thus my confusion about your wording (search here for the term ).

Text programs can be used to write highly parallel code too, it's just not as intuitive.

LabVIEW is just parallel automatically. (Have a look at my benchmarks. My fitting program can calculate around hundred spectra per second on one CPU core, but thousands if we have plenty of cores. details).

[Mark_Yedinak]

Ok, I guess I'll add my own two cents. I rarely use the file view. When I do it is when I am refactoring code and moving it on the disk. I move things via the file view because the project gets updated automatically.  I can update my SSC to move files as well so this will be a two step process. For everything else I use the project view. I also work with a team that takes the time and effort to define reuse libraries. So, much of what is included in a project are libraries being used within this project. Libraries help to minimize cross-linking of code. However they also take some discipline to organize your code on disk. Now we take this one step further by using packed projects libraries (PPLs). So we have fixed locations for the PPLs and our projects will reference those areas. The code for the reuse libraries is kept in a different location and a different repository. General projects work off the common location where the PPLs are stored and the code for them is separate and only touched when modifications are needed. Over the years many of our libraries have become very stable and don't require changes very often. I believe we are approaching the 200 count for the number of PPLs we have. About half are plugin libraries that get dynamically loaded at run time. The other half are core libraries and the abstract definitions of the plugins.

In short, in order to minimize issues with updating your code you first and foremost should be using source code control. Second, begin to look for code tat can be reused and start organizing around that. Then put project specific code in it's own location.