Xnode Dirty Dot

[jacobson]

A while ago I developed an Xnode that has an ondoubleclick ability which opens up a configuration window. I noticed that every time that ability was called, even if you immediately closed out of that configuration window that it would produce a dirty dot in the owning VI. This seemed to happen with the ondoubleslick and onoperateclick abilities even if there were no replies or added code to the abilities themselves. I attached my Xnode which demonstrates this behavior. 

 

I was wondering if there was any way to prevent a dirty dot in the owning VI if nothing has changed in the Xnode's state or generated code.

 

-Matt J

Random Xnode.zip

Edited February 14, 2016 by jacobson

[hooovahh]

All I can say is you're not crazy, and there probably isn't anything we can do about this.  I modified your OnDoubleClick2 in the hopes that adding a cancel output, which would then not add any states (like get terminals and redraw), but as you stated the dirty dot appears even if you don't add those states.  

 

Next I looked at the VI property Modifications >> Block Diagram Mods Bitset, this tells you what on the block diagram is unsaved.  If the value is 0 then there are no unsaved changes.  This value is still 0 when the OnDoubleClick2 VI is ran, so the bit is being set after the OnDoubleClick is done running, which to me means there isn't really anything we can do about it.  The second time I double click the XNodes it does have a non zero value, meaning it is reading the bit sets on the calling VI.  But even if we were able to clear those bits indicating a modification was made, those bits aren't set until after the VI runs.

 

Oh and another thing I checked was maybe in newer versions of LabVIEW there was an OnDoubleClick3 which fixes this, but in 2015 there isn't.

[Darren]

I've noticed similar behavior for other abilities. For example, if you click the drop-down on an Error Ring, then click cancel, your VI still gets a dirty dot even though you didn't change anything. I don't know of any way around this behavior.

[jacobson]

Thanks for the input. I kind of expected that we wouldn't be able to change that behavior because some of the LabVIEW Xnodes do this but I figured I would ask since my Xnode is much simpler than a lot of the ones used in the development environment.

 

Looking forward to the presentation next week hooovahh.

[hooovahh]

Looking forward to the presentation next week hooovahh.

 Don't expect anything too mind blowing, it's basically all stuff you can research on your own, with a few added breakdowns, and experiences.

[dadreamer]

Started playing with XNodes a bit and noticed the same behaviour as well. Really upsetting. But there is the solution. Just send FailTransaction reply in a Cancel case in the OnDoubleClick ability of your XNode and that 'dirty dot' never appears! That's exactly what the Timed Loop XNode does internally.

Quote

FailTransaction:
LabVIEW will abort the current transaction. This will avoid putting transactions in the undo list when the user just hit cancel.

Looking at this description I get the impression that this reply was invented precisely to overcome that bug (was even given its own CAR #571353).

Similar thread for cross-reference: LabVIEW Bug Report: Error Ring Edit + Cancel modifies the owning VI