Facade VI opens dirty

[elset191]

I have an XControl who's Facade VI always opens dirty.  Even when I hit Revert it goes straight to dirty again.  The unsaved change is a display attribute changed on the front panel. 

The Facade VI has two other XControls on it, and neither of their Facade's open dirty.  Also, none of them have this issue anymore.  Even when I drop the XControl whose Facade does open dirty onto a VI, that one doesn't ask to be saved just by opening it.

I haven't the vaguest idea why this might be happening.

I (hopefully) attached a flash video that illustrates the behavior.

[James_D]

And this is being opened in LabVIEW 8.6.1?

[elset191]

Correct.

I'm not sure if it's related, but when I open up a project that uses this particular XControl, it and all of its dependencies are locked right from the get go.  This happened to me once before because I had a subVI in the XControl that it and a sub-XControl both called from their facades.  I moved the subvi into the other XControl and they stopped opening locked.  I'm trying to track down what might be causing this right now.

[James_D]

It looks like this may be related to a known issue that was corrected in LabVIEW 2010. Do you have access to LabVIEW 2010 to try to see if this is in fact the same issue?

[elset191]

To get the code to run in my 64 bit LV 2010 (7days left on eval.) I had to change a bunch of stuff to get rid of IMAQ VIs and also the 3D graph doesn't work in 64 bit.  Anyway, after I did all that and got everything to be not broken, the VI still opened dirty.

This XControl is over a year old, and just recently started opening dirty as I was going through and deleting stuff that isn't used anymore (typedef's, properties, etc).  Not sure if that helps with anything.

[elset191]

I've discovered that opening this particular Facade VI causes a Data Change event in one of the XControls on it's Front Panel.  I'm not sure why this is the case, or how it's even doing it.  But, the Data Change event in the sub-XControl sets it's Display State Changed to true, which causes the dirtyness. As I stated in my original post, when I drop the sub-XControl on a blank VI, that VI is not opening dirty, i.e., not firing a data change event for the XControl.

For now, on the block diagram of the sub-XControl data change (as well as panel size event) I have added the following code, which allows it to not go dirty.  Obviously, this is not ideal and I would still like to solve the actual problem.

[elset191]

---

@elset191 wrote:

As I stated in my original post, when I drop the sub-XControl on a blank VI, that VI is not opening dirty, i.e., not firing a data change event for the XControl.

---

As it turns out, the Data Change event is firing when it's on it's own VI according to my break points.  However, it's not causing that VI to be dirty like the other Facade VI in question. 

Why would loading the XControl fire a data change event in a sub-Xcontrol?  Why would it cause a dirty Facade, but not a dirty regular VI?

[James_D]

Can you post the X Control? Also, are you using the FIRST edition of labVIEW?

[elset191]

No, I'm not using the FIRST version of LabVIEW, I'm using 8.6.1f1, though I still have the WPI libraries installed.

I can give you my code, but I'd prefer not to post it on the public forums, due to it being work related.

[James_D]

It feels like this is probably something getting set as a part of the loading process. Perhaps something included in your project is from an older version of LabVIEW or the switch is somehow being flipped unintentionally as LabVIEW compiles the XControl. Have you performed a mass compile on it?