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

[3d0g]

I would've added into the thread I was reading, but I've seen on countless occasions as I've read here people getting chewed for derailing threads with add-on thoughts/questions.  Lest I be chewed for such while I'd still like the question answered by those more knowledgeable about LabVIEW than I, I am starting a new thread to ask.

This is in response to "installing newer version of LabVIEW updated all my old code", a familiar nightmare experienced by many as I've gathered learning LabVIEW.  Here's my question:

I have learned that although it's convenient just to work with a vi, one should always work from inside a project, always.  Thus far, I agree with that advice.  In a LabVIEW project, there are two tabs at the top: "Items" and "Files."  In my simple terms, "Items" is how you want to arrange your project, logically, while "Files" is how your project really is, with respect to the environment in which your project resides.  Hence, to avoid issues with auto-updating that which shouldn't be updated by saving (clicking that necessary and reasonable button) the project you're working on, the solution is to monitor "Files" and watch out for unintended (vertical) ties creeping in during your development.  This is how an old project and a new project can remain isolated from one another.  Do you LabVIEW veterans out there agree or disagree?

Thank you.   

[santo_13]

The most important skill is to not just blindly click "Save All" and selectively save the files that you modified and most important - maintain files in a source code control (like SVN, Git etc.,) to revert to old version in case of a mistake.

[3d0g]

You are either not a LabVIEW veteran or you do not want to commit yourself to agreeing or disagreeing.

I agree with what you said, to not blindly save, but I'd really like to hear about this from those who have been there and know the ins and outs of this.

It'd seem to me, green relatively speaking, that "Files" will reveal something like an llb used in a projectX being crossed-linked to another projectY, inadvertently, by some tiny blip of a vi within the llb.  It'd seem, to me, there'd automatically appear an unexpected vertical tie between the two projects in the "Files" display.  No?  Or is there still a danger?

[billko]

---

@3d0g wrote:

You are either not a LabVIEW veteran or you do not want to commit yourself to agreeing or disagreeing.

I agree with what you said, to not blindly save, but I'd really like to hear about this from those who have been there and know the ins and outs of this.

It'd seem to me, green relatively speaking, that "Files" will reveal something like an llb used in a projectX being crossed-linked to another projectY, inadvertently, by some tiny blip of a vi within the llb.  It'd seem, to me, there'd automatically appear an unexpected vertical tie between the two projects in the "Files" display.  No?  Or is there still a danger?

---

Santo has an order of magnitude more solutions than you have posts.

If you make it a practice to save the files you actually edit as soon as you're done editing, it will make it a lot easier to decide which files should be saved.  If you make sure to separate compiled code from the source, you will almost never run into this issue, provided you don't explicitly open those files in the dependency area.  Separating the compiled code from the source code should be standard practice if you use versioning software anyway (which you already do).

[Kevin_Price]

---

@3d0g wrote:

It'd seem to me, green relatively speaking, that "Files" will reveal something like an llb used in a projectX being crossed-linked to another projectY, inadvertently, by some tiny blip of a vi within the llb.  It'd seem, to me, there'd automatically appear an unexpected vertical tie between the two projects in the "Files" display.  No?  Or is there still a danger?

---

No.  The files that are part of "projectX" will have no knowledge whatsoever of whether they're also included as part of "projectY".  So over in the Items view for projectX, you will only see the files and dependencies that are relevant to projectX itself.  LabVIEW does *not* (and really *should* not) try to "reverse navigate" from every file to figure out whether there's any other project anywhere on your hard drive that might also include reference to the file in question.  Imagine how long it'd take to update the Items view if your entire hard drive had to be scanned before it could report back!

In brief: while in projectX, the Items view combined with your personal knowledge and practices *can* be valuable for pointing out files or dependencies that reside in a location that is not *isolated* to projectX alone.  But only if *you* are following good practices about organizing the code for your projects, for reuse, etc.  It isn't fully automatic, it's a combo of what LabVIEW will show you and what you know about the way you organize things.

-Kevin P

[altenbach]

---

@3d0g wrote:

This is in response to "installing newer version of LabVIEW updated all my old code", a familiar nightmare experienced by many as I've gathered learning LabVIEW.

---

For completeness and to avoid confusion, I recommend to always include links to quoted discussions to keep us all on the same page. I assume you are talking about this discussion.

---

@3d0g wrote:

I have learned that although it's convenient just to work with a vi, one should always work from inside a project, always.  Thus far, I agree with that advice.  In a LabVIEW project, there are two tabs at the top: "Items" and "Files."  In my simple terms, "Items" is how you want to arrange your project, logically, while "Files" is how your project really is, with respect to the environment in which your project resides.  Hence, to avoid issues with auto-updating that which shouldn't be updated by saving (clicking that necessary and reasonable button) the project you're working on, the solution is to monitor "Files" and watch out for unintended (vertical) ties creeping in during your development.  This is how an old project and a new project can remain isolated from one another.  Do you LabVIEW veterans out there agree or disagree?.   

---

A project is just a file containing information where VIs are located, how builds are specified, and how things are arranged in the project window, etc. If you open a project, all dependencies that are not explicitly mentioned are also included. A project does not contain any LabVIEW code. Installing a new version of LabVIEW will NOT update any of your code. Of course once you decide to switch to the new version, things need to be updated and saved. Nothing wrong with that. Nothing prevents you from also keeping the old LabVIEW version and keep using it to work on the old projects. I have done this for decades without any issues.

Also note that VIs within the same major version are always compatible. For example if you have VIs in 2020 SP1, they can be opened in 2020 (original).

Most of your description is quite incomprehensible and probably needs clarifications. For example I have no idea what "vertical ties" are or where a "reasonable save button" is. Once I decide to upgrade a project to a new version, I typically create a source distribution in the old version to have a clean dependency hierarchy and then open and save that in the new version. No old code will ever be touched by the new version. (One of the barbs is that you cannot include the project file when creating a source distribution, but you can always copy it manually. I even have a build script that does it automatically). If you have common code in e.g. user.lib, you simply need to include that in the new LabVIEW install. Each LabVIEW version has it's own user.lib, No crosstalk!

Maintaining good hierarchies on disk and also use reasonable source code control will avoid any problem. If things go wrong, there is always the "save for previous" tool. 😄

[rolfk]

I really never have used the Files view in a project in my 30 years of LabVIEW programming (partly because the LabVIEW project didn’t exist in LabVIEW before 8.0 and I even skipped that and only used LabVIEW 8.2 after 7.1.1) and since you want a clear agree or disagree statement, mine would be a strong disagree! You did ask for that 😀.

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. Some people only seem to want to add the top level VI to the project, and find the flat Dependency view below enough to find the VI in question within 1000ds of them (as real world projects often get), or they may also only rely on the Files view to have an overview, I'm not sure. Some go as far as randomly throwing some (or even all) of the VIs together with the main vi in the project view in one single level, most likely as a challenge for anyone having to maintain the project after them, by offering them a nice seek and hide game 😁. 

The main technique I rely upon however is a sound source code control solution. Without that programming real applications (not so much for quick and dirty proof of concept things) is like walking a rope a mile above ground without any safety net.

And anything for a specific project except vi.lib, user.lib and instr.lib VIs always has to be stored beneath a common top level directory for that project and that project only. Make sure to use Save As and to check you are in the right location. It takes a few seconds to check during saving and many minutes to clean up the mess if you did the saving wrong! Default configuration files for the application need to be present too in there specific folder and the requirements specification, any documentation, data sheets, electrical schemata, and customer communication all come in their specific subfolder hierarchy besides the Source code folder. All that is as whole regularly committed to the source code control system. Any cross contamination to out of tree files needs to be solved immediately. No excuse! Files not (anymore) used for the actual project need to be moved in their own Trials, Trash or similar folder if you don't want to delete them right away.

[altenbach]

I do occasionally use the "files" view, because sometimes I look at forum code while working on a project and by oversight, some of my own new subVIs might get saved in the "downloads" folder by accident after that. A useful (and sometimes dangerous) feature in the flies view is that we can actually drag files around directly and it will change their location on disk, updating the hierarchy and dependencies.

[3d0g]

compiled code vs source

In the inline programming world I know what that means, but what does it mean in the LabVIEW programming world?

Also, as you are a forum veteran, how do you AND anyone else reading know this response was to you?

[3d0g]

I was speaking of the "Files" view (for its vertical ties indicators) not the "Items" view.  Does this change your response?  In summary of what I said, the "Files" view shows all ties.  Agree?  Disagree?  The danger is eliminated by monitoring the "Files" view for vertical ties.