LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

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

0 Kudos
Message 11 of 19
(290 Views)

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

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 12 of 19
(287 Views)

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

0 Kudos
Message 13 of 19
(273 Views)

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?

 

 

0 Kudos
Message 14 of 19
(261 Views)

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

 

"Do Not Save Automatic Changes"

 

(Under "Environment")

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."
0 Kudos
Message 15 of 19
(254 Views)

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

0 Kudos
Message 16 of 19
(240 Views)
Yes, that is the one.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."
0 Kudos
Message 17 of 19
(231 Views)

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

0 Kudos
Message 18 of 19
(226 Views)

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

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 19 of 19
(207 Views)