LV Compare VI Icon (B/W) difference

[DelGizzi]

I am using LV Compare and one of my VIs keeps saying that I have changed the VI Icon (B/W).  I usually just don't commit this vi, but its frustrating to have it change and manage it every time.  Even if I do save and commit, the next time I load it up I see the same difference once the VI is run.

Can someone elaborate on what that detail means?

[Bob_Schor]

A long time ago (I know it was present in LabVIEW 7, but may have vanished in 8 or 9), VI Icons existed in triplicate -- 16-bit color, 4-bit color, and 1-bit (B/W) color.  If LVCompare is saying that the two VIs differ because the icons differ, the easiest solution is to copy one over the other (so they are, indeed, identical).

What version of LabVIEW are you using, and in what version was the VI written?

Bob Schor

[DelGizzi]

The code is new.  I am writing in 2015 now, and I can't recall when the VI was originally created, but definately in 2014 or 2015 versions of LV.  

I did a text diff on the file and it looks like there are other changes in the file, all related to class data updates.  I know that class data changes sometimes causes VI changes, but I was hoping the icon thing was different.  It looks like something in the icon line is triggering this lvcompare difference, the binary data after  _ni_LastKnownOwningLVClassCluster has canged slightly.

Looks like there is probably nothing to do here except wait for better a better diff tool.  Thanks for your input Bob

[Matthew_Kelton]

You said that if you commit, the difference comes back after the VI is RUN?

Does this mean if you just open the file and close it, then the comparison does not detect the icon change?

If so, have you confirmed the VI's icon is not being modified via one of the VI methods for the setting icon?

[DelGizzi]

Hi Matthew,

Yes I did say that, but that was slightly incorrect.  If I save everything and commit and then re-open there are no changes.  However, I am pretty sure the changes were coming when I changed class data (the class data of the class this VI belongs too).  For some reason there is some informatino in the Icon section of the VI text that is changing slightly, and lvcompare is interpreting that as a B/W change.  So in the development process, I was constantly changing class data, and it appeared that the same change kept appearing.

Now I am not certain why this VI Icon data is so tied to the class data when other VIs are not, but for the meantime Im not going to worry about it.

[JonP]

I too am seeing this issue in LabVIEW 2017. In my case LabVIEW wanted to save the VI because SubVI calls were modified (not noticeably...), and subsequently the only reported difference between the two versions was the VI Icon (B/W). A further complication is that I recently went from SP1 to SP1 f3. I suspect NI are saving some flag information in (what was once) the B/W VI Icon.

[550nm]

I'm seeing this too. When I SVN "Commit", large numbers files are flagged as changed because of this, though, it's not obvious why without comparing each one.  Could this be a consequence of having different Icon-editor settings - or different icon TEMPLATES - on different development stations?  It seems that this change is happening even without opening the VI/icon-editor. I'm using LV2014 (mostly).

[Rannoch]

I can also confirm this issue and it is really annoying.  I'm using LabVIEW 2016.

It appears to be developer based.  If I check in the "changed" VI in my class than I have no problems.  However if my co-worker opens up the project the specific VI shows a change.  If he checks it in the problem repeats for my machine and we continue to bounce the annoying part back and forth.

We all use the same version and installers for LabVIEW.

[Briton]

HI

Got the same problem (LV2015)!

NI, don't you have a solulution for this problem, please?

Thanks in advance

Bjarne

[Bob_Schor]

Could this be the problem of including Compiled Code in the Repository?  I also used to get very frequent (what-seemed-to-be-trivial) Commits and Updates when I was largely (or so I thought) just "looking at" the code.  I recall hearing about "Separate Compiled Code from new project items" (a Check Box in the Environment section of Tools, Options) and then learned about a Property Project (right-click the top, Project, entry of an open Project, select "Properties", and check out the button "Mark Existing Items ...").  This might explain what you are seeing ...

Bob Schor