Copy project breaks class variables

[s.h._tech]

Hello everyone,

I am having trouble rebuilding my project. I regulary save my project since I can not trust Labviews regarding changing typedefs, class controls and constant variables (see this ). 

I changed a typedef (which is inside a class control) and now some of my 'Unbundle_by_name' are wired different (random?). 

I tried opening an older version and there are also broken links with randomly wired 'unbundle' values. Funny enough not the same variables as in the original version. I also built an exe from the older version, which is still working fine. Only the source seemed to be affected.

Before I did all that I carefully closed LV, looked in the task manager if anything LV related (not NI) is still running and only opened the older version.

How can LV change the source of an untouched project? Are there some dependencies which are permanently linked to every copy of the project? Is it possible to revert the old version to the safe state from which I build the exe?

[wiebe@CARYA]

Sounds to me you need source code control...

Not that I ever have any of the problems that you describe. But I've been doing this for 20 years, and I have probably developed habits that I don't even know of.

AFAIK, The project only stores it's contents, not the relation between content. This is all handled by the code itself. A VI does store paths to dependencies, and as long as the relative path is what is expected, everything is OK. I'm not sure where you, or your code, go wrong. The only way to find out is to describe in detail what you are doing. I suspect that maybe not everything Is stored under the project, that would be problematic.

[s.h._tech]

In the beginning I stored VIs across multiple projects (huge mistake). Now I carefully create VIs in the dedicated project folder.

The only exceptions are Labview libraries or dll which are stored in a separate library folder.

I also noticed when opening a project (after startup), a '*' appears next to the project name. When I try to close it LV wants to save the 'changed' files. Something must happen pre-opening that changes something in the project.

Are there some prebuild/ linking functions in the settings?

How can an IDE change files just from opening?

I think this might be the problem. Some links/dependencies are rooted deep somewhere in the project. 

[s.h._tech]

UPDATE: This effect does not happen when I use zipped projects.

[wiebe@CARYA]

---

@s.h._tech wrote:

I also noticed when opening a project (after startup), a '*' appears next to the project name. When I try to close it LV wants to save the 'changed' files. Something must happen pre-opening that changes something in the project.

---

Not per se.

I've occasionally noticed that a save all does not save all. Or the save all itself effects the files. So, when I save all and than reopen the project, a save all saves files despite the earlier save all.

So this could be a similar thing. That it's not a pre-open problem, but a save all problem.

[s.h._tech]

I have noticed the 'Save_All' issue as well. Therefore I completely closed LV to release all links. Apparently something keeps running in the background that remembers some dependencies.

Is there an official design guide for saving as older version? Keep links to certain variables, classes and dependencies contained.

I tried the versioning in LV15 but had even worse results (broken links, changed variables). 

Maybe I just do not understand how LV saves/ links and compiles its sources, but as far as I observed it is strangely convoluted than standard programming languages.

[wiebe@CARYA]

---

@s.h._tech wrote:

I have noticed the 'Save_All' issue as well. Therefore I completely closed LV to release all links. Apparently something keeps running in the background that remembers some dependencies.

---

That doesn't suffice.

Sometimes a save all, close, open, save all, close is required.

---

@s.h._tech wrote:

I tried the versioning in LV15 but had even worse results (broken links, changed variables). 

---

Where does this come in? I don't recall you mentioning saving to previous before. That will complicate things quite a bit. It will not solve anything.

[s.h._tech]

Not saving to previous (another deathtrap).

I meant that I tried versioning in LV15 with no success. I was unable to trust the files from a previous build since variables and unbundles might have been changed. This lead to quite some troubles in my statemachines, since many 'constants' I set defaulted to some value, which I have never seen in a real programming language.

Usually when I set a variable (x=0), it stays until I (!) overwrite OR refactor it. No IDE should interpret constant values and just set it to a default value, when it was clearly defined somewhere in the source. Or in the case of 'unbundle'  guess the next variable with the same datatype (e.g. output limits).

[wiebe@CARYA]

---

@s.h._tech wrote:

Not saving to previous (another deathtrap).

I meant that I tried versioning in LV15 with no success. I was unable to trust the files from a previous build since variables and unbundles might have been changed. This lead to quite some troubles in my statemachines, since many 'constants' I set defaulted to some value, which I have never seen in a real programming language.

---

Don't do versioning on VI\Control bases!

This is tricky, but actually works predicable.

If you "save as" an enum for instance, all instances *in memory* are updated. Al VIs not in memory will be 'corrupt'.

Use source code control for controlling your source code. This includes versioning.

[Mark_Yedinak · Accepted solution]

While there are some things you need to be aware of when working with LabVIEW, it is not as bad as you are describing. I think something in your workflow is causing the issues. I have been working on very large projects with multiple developers for well over 20 years and don't run into the issues you describe.

Some things to consider, any of your reuse code should be in their own library. Add libraries to your individual project files. This is the best way to share code between multiple projects. Always use projects for your code. Everything we do will be placed in a project unless it is throw away experimental code. I always mark my VIs to "separate the compiled code from the source". Use source code control. Do NOT rely on block diagram constants of typedefs to retain their value if you change the typedef or update default values in the typedef and expect the block diagram constant to change. Typedefs define structure, not values (expect strict typedefs). I either set the defaults explicitly on th eblock diagram wiring them into a bundle node or if I use it in multiple places I will create a VI which simply outputs the cluster and the block diagram is nothing more than a bundle with my desired constant values.