Mysterious unsaved changes in project: Class type definition stored in member VI?

[bokorpet]

Btw, this ancient blog entry seems to describe my very problem: http://thinkinging.com/2008/11/10/when-to-commit-changed-vis-caused-by-type-definition-changes/

Still, it's a msytery to me what modifications cause what unsaved changes.

And it would be good to know if it's a "feature" or a bug.

Peter

[Norbert_B]

Peter,

just for clarification:

These issues only occur if you expand private data of a class which includes association to other classes (so the private data includes at least a single DVR to another class)?

Or is the other way round: The issue only occurs with classes which are associated to another class but have no association within themselves (so another class has a DVR to this class as private data while the class has no DVR to another class)?

Or does it seem arbitrary?

Mass compile, as the name implies, forces a recompile of the specified sources. If "separate compiled code" is enabled, it re-creates the viobj for the vi in the vi object cache. So it shouldn't have effect on the VI.

If the option is disabled, the compiled code is attached to the source file and saved.

It is recommended to use mass compile if you upgrade to a newer LV version and compiled code is part of the source files.

What comes to my mind:

Did you already cleared the vi object cache (Option "Clear Compiled Object Cache")? I find it possible that there is some kind of corruption....

Does the issue occur on a specific machine or is it reproducable on different development PCs?

Norbert

[bokorpet]

Hi Norbert,

it seems arbitrary. I mass compiled and cleared the cache and just by opening the project dozens of unsaved changes would appear. So indeed, it doesn't seem to be connected with new cluster elements of a class.

As I don't want to waste anyone's time, I'll try to reproduce the behaviour in small scale and post it in this thread. But it may take a while as I have no clue what the root cause could be.

Thanks again,

Peter

[bokorpet]

Hi, it's me again.

Even stranger are the unsaved changes explained by LabVIEW as "Name or location of VIs in the file system changed. The VI's name was changed outside of LabVIEW, or one of its subVIs was found in a different directory." (see also http://lavag.org/topic/15014-dirty-dots/).

It's absolutely not true that they have been changed outside LabVIEW.

What's going on here?

[mikeporter]

To cause LV to not save the automatic changes, click the option:

"Do Not Save Automatic Changes"

(Under "Environment")

Mike...

[bokorpet]

Hi Mike,

in my LabVIEW version (2012) the option you're referring to is under another option which has to do with read-only VIs (see snapshot - unfortunately in German).

I'm not sure it's what I'm looking for, is it?

Peter

[mikeporter]

Yes, that is the one.

Mike...

[bokorpet]

Thanks Mike.

I'm not sure though what this option really does. In particular, I don't want to suppress changes, I'd like to understand them and avoid them happening.

Peter

[Norbert_B]

Just to update this thread:

Several VIs have been identified which are still including compiled code. It also seems that one VI is corrupt.

That being said, the clear expectation is that separating compiled code from source code will NOT create "dirty dots" when the project/classes are loaded into memory. Adding properties to classes should create dirty dots only for the class itself, not for VIs calling the class (including class methods).

Norbert