Dirty Dots

[mje]

So, I have this VI that always has a "dirty dot" on it. The second it's opened, it appears dirty with the little asterisk in the window title bar, and I'm forever being prompted to save changes to it every time I close out my project. Even if I don't open it, only load it by virtue of it being in the project, it becomes dirty and when I close the project, I'm prompted for a save.

I'm told by LabVIEW that "Name or location of VIs in the file system changed", with more details being provided as "The VI's name was changed outside of LabVIEW, or one of its subVIs was found in a different directory." Well thanks for nothing. Not only is that a lie, it's completely unhelpful. The VI in question has only a handful of subVIs,

I've rebuilt the entire VI from scratch being careful to manually drop each subVI directly from the project explorer onto the diagram so as not to accidentally grab the wrong version of something.

I've deleted my compiled object cache, and performed a mass recompile of the entire project hierarchy. Twice.

I've also tried generating an export from SVN, thinking that somehow a VI was being picked up from the cache maintained by SCC, no luck.

All of this and that damned dirty dot just keeps popping up.

Since LabVIEW seems convinced something has moved, it would be really helpful if it actually told me what moved. I've tried to no avail by incrementally blocking smaller and smaller portions of code out with diagram disabled structures to identify the culprit, but the results are at best inconsistent: about the only thing I can reliably do is disable all the code to have the VI become stable.

Any ideas?

[Grampa_of_Oliva_n_Eden]

I keep the auto-populate off in the projects I start and the dirty dot is alomost always due to changes that need saved.

When I open project from others that do use the auto-populate, I often see the dirty dot and the message you reported.

Now back to my non-autopopulate....

I had an XControl that always triggered the dirty dot.

A similar XControl in one of NI's toolkits (maybe sound and vibration) did similar.

THat is all I can share.

Ben

[PaulL]

Some causes of "dirty dots" of which I know (as of LabVIEW 2010):

1) Calling "system VIs": http://digital.ni.com/public.nsf/allkb/D4032A485C9F18C1862576D6007681F4

2) Opening a copied RT VI (i.e., in a new location on disk) with an FPGA VI reference (nondynamic).

3) A dirty dot appears in the project if you open a library (e.g., class library) where the contents are set to (Custom?) arrangement. Changing to Arrange by Name fixes this.

4) Changing a strict typedef in the private data of a class in one project may keep making you save a different project that uses the class. I usually make a trivial change (e.g., arrange horizontal then vertical again) to force a recompile. Then we're OK.

5) As Ben already mentioned, using autopopulating folders causes this a lot. We only use virtual folders anyway.

I'm not sure any of these apply in your situation.

[Phillip Brooks]

I saw a strange case of dirty dots that I attributed to the inplaceness algorithm. I posted an example here.

The gist of the problem had to do with changing the error wire in a subvi from error-in to error out to passing the data through a native function that MIGHT modify the error. The subVI must contain info that allows the inplaceness algorithm to short-circuit the wire. When I changed the low-level vi, all calling VIs indicate they need a save.

Don't know if this is what you are seeing, but it made me crazy for some time.

Inplaceness is synonymous with insidiousness ...

[mje]

Well this is fun. The relevant section of code:

The above code works and doesn't cause the VI to be dirty when loaded. The original code had a property node in place of the string of five accessor methods I highlighted in red. Even now, if I delete the accessor VIs and drop a property node instead, I'll get the dirty dot problem. Even though the two pieces of code should be equivalent according to everything NI has said with respect to classes and property nodes.

Thank you very much for all the clues. The bit about in-placeness clued me in to looking at the subVIs more closely, and eventually I homed in to the property node using some creative sleuthing with the diagram disabled structure.

Fun fact: even having the property node on the diagram in a disabled case causes the dirty dot to appear when the VI is loaded. Weird.

[jgcode]

What version of LabVIEW are you seeing this in?

[mje]

2011.

[GregSands]

Every so often I have a VI which always opens with a dirty dot, and the reason is "Object(s) modified on the block diagram". Is there any way to determine which object(s) that might be? It would be great to be able to double-click the message in the list of unsaved changes and go to that object, or to a list of objects. I've seen this in all recent versions of LabVIEW including 2011.

[asbo]

Every so often I have a VI which always opens with a dirty dot, and the reason is "Object(s) modified on the block diagram". Is there any way to determine which object(s) that might be? It would be great to be able to double-click the message in the list of unsaved changes and go to that object, or to a list of objects. I've seen this in all recent versions of LabVIEW including 2011.

Keep a revision of the VI which opens with the dirty dot, save to it a different file name, then do a diff (Tools > Compare) between the two.

[GregSands]

Keep a revision of the VI which opens with the dirty dot, save to it a different file name, then do a diff (Tools > Compare) between the two.

I tried this -- both VIs need to be open to compare them, and of course the automatic changes are applied when opening the VIs, so there's no difference. Or am I doing something wrong?

[jdunham]

Have you checked that the VI's path in the stored in the lvclass file matches the actual VI path?

[asbo]

I tried this -- both VIs need to be open to compare them, and of course the automatic changes are applied when opening the VIs, so there's no difference. Or am I doing something wrong?

D'oh. Didn't think that one through. Touché.

[GregFreeman]

Sorry to resurrect an old thread but I am currently running into a similar issue. The only commonality I can find is property nodes are used in the VIs. When I click list unsaved changes, all VIs in question say "Some VI Attribute Modified" and in the details say "Some attribute of the VI was changed, such as the breakpoint, data logging, or VI Properties options."

 

This is causing frustration when using Git because there are changes to the binary apparently that aren't captured by a diff and everyone having to resave is causing conflicts that don't really exist in terms of code functionality changing. I am going to branch the code, replace the property nodes with accessors and see what comes of it. But, in the mean time I figured I'd see if anyone else has determined anything further relating to this in the past 2.5 years.

 

Edit: I should note, I just realized once I save locally the dirty dots don't reappear. But after a merge they often do. Maybe it's some discrepancy between a project my coworker is using locally and mine (autopopulating folders or something). Just speculation; I'll dig into it more.  Also, I have source code separated from compiled on these files.

Edited March 17, 2014 by GregFreeman

[mje]

Nope, I got nothing. Sorry. Sincerely I am, if for no other reason than selfishness: my life would be way easier if not for this behavior.

 

One of our project's spanning a few thousand VIs has this problem with hundreds of the VIs. I've given up. Development is completely non-portable. Everything's stable as long as you're on a single machine, but otherwise we're SOL. Wish I had an answer for you, but I don't.

 

See this discussion at the dark side. I have several arcane "best" (read: awful) practices, but even then it may very well be a crapshoot. New projects of reasonable size only come along here every few years, so I haven't had a chance to start anything sizeable up with what I've learned from that thread. The typedef thing discussed in the link may be real, it may be a red herring, I just don't know.

[GregFreeman]

Nope, I got nothing. Sorry. Sincerely I am, if for no other reason than selfishness: my life would be way easier if not for this behavior.

 

One of our project's spanning a few thousand VIs has this problem with hundreds of the VIs. I've given up. Development is completely non-portable. Everything's stable as long as you're on a single machine, but otherwise we're SOL. Wish I had an answer for you, but I don't.

 

See this discussion at the dark side. I have several arcane "best" (read: awful) practices, but even then it may very well be a crapshoot. New projects of reasonable size only come along here every few years, so I haven't had a chance to start anything sizeable up with what I've learned from that thread. The typedef thing discussed in the link may be real, it may be a red herring, I just don't know.

I just pulled in new changes and am getting a similar "typedef" changed message in other files. The strange thing is, I can't find a typedef in the class anywhere? Maybe it's coming from a static dependency, but a brief scan of stuff doesn't show anything. Unfortunately in this case, no property nodes are used. However, almost all the VIs that LabVIEW says have "changed" are accessor VIs. There is some parallel between these things, that's for sure. Maybe I'll just use static VIs instead of accessors in property definition folders from now on and see if that alleviates the issue. 

 

Edit: one additional thing I've seemed to notice is it is often (not sure if always) a child class that has these issues. Maybe just a coincidence, butit seems my base classes don't have a problem. Note though, this isn't confirmed.

Edited March 18, 2014 by GregFreeman

[shoneill]

Class private data is a typedef.