VI pretends to be modified

[matthias_at]

When opening one of our VIs (in Labview 2017/64bit), then immediately the asterisk (*) appears in the title bar, and when closing the file again Labview asks for "Save changes before closing?". Clicking "yes", the file is saved and closed. Reopening the file repeats the story.
It seems like something in the front-panel is self-modifying itself when opening the VI. Unfortunately I cannot track it down by systematically deleting front panel items, because this renders the VI non-executable, and for some reason the problem disappears as long as the VI is not executable.

Clicking on "List unsaved changes" shows two entries:
 Cosmetic(s) modified on the front panel.
 Display attribute(s) changed on the front panel.
But it doesn't tell which one.

This repeated saving is problematic for us, because it keeps filling up our file versioning system with dummy file versions.

---> How can I get rid of this self-modification? Is there a practical way to identify the responsible front-panel object?

Many thanks in advance.

[Ben]

If you grab all of the objects on the Front Panel (ctrl-a, ctrl-c) and paste them on the FP of a new VI (ctrl-n), does that new VI exhibit the same problem?

If so start deleting half of the FP objects until you find the widget that is causing problems.

The only other ideas I can offer is trying a mass compile (ctrl-shift run arrow) or possibly an XControl that doesw something when the state changes.

Ben

[Yamaeda]

SCCs usually sets Read Only on checked in files. Set the LV Environment option "Treat Read Only as locked" to true, and it shouldn't recompile as easily.

/Y

[matthias_at · Accepted solution]

Thanks Ben for this suggestion.

Indeed the problem persisted when pasting all front panel objects into a fresh VI, and we could identify the problematic object: it is a Digital Waveform Graph. Please find attached a stripped down VI which exhibits the problem.

Apparently, when clearing the graph and setting this as a new default, the problem vanishes. This is a reasonable workaround for us.

Note that this issue surfaced when we ported the VIs from Labview 2015 (64 bit) to Labview 2017 (64 bit).

Many thanks,

Matthias

[matthias_at]

Thanks Yamaeda for this hint. The policies of the file versioning system for this project are set such that the files remain writeable at all times. But in other contexts the suggestion might be a valid workaround.

Matthias