03-23-2011 08:44 AM
Yes I've tried mass compiling. When it finishes it asks me to save the Facade VI in question, and it still opens dirty thereafter. Do you have an email I can send my code to?
03-24-2011 05:16 PM
Interesting results. When I resave your XControl it immediately becomes corrupted. Going to make some adjustments and see what is causing this, it might be related.
03-25-2011 04:56 AM
Are you setting the state changed boolean in the Display State Change event as well? This event is fired when the control is loaded (even though the documentation for it does not say that it does).
03-28-2011 10:50 AM
@tst wrote:
Are you setting the state changed boolean in the Display State Change event as well? This event is fired when the control is loaded (even though the documentation for it does not say that it does).
Nope
03-28-2011 03:49 PM
Hi Tim,
I wanted to let you know that I am currently looking into the situation with James. We'll keep you updated on our findings.
03-29-2011 11:06 AM
@che T. wrote:
Hi Tim,
I wanted to let you know that I am currently looking into the situation with James. We'll keep you updated on our findings.
Thank you very much.
Have you guys read the readme I included in the .zip file? What I'm getting at is have you encountered this issue?
03-29-2011 11:20 AM
we're getting a cpp issue, but not that particular issue. Have you ever got a crash on something called filelinkref.cpp with this project?
03-29-2011 12:05 PM
That doesn't sound familiar. It's always been the one I mentioned as far as I can remember.
03-29-2011 01:30 PM
Okay, it turns out the cpp issue I was running into was unrelated to your problem. However, I have found a different known issue than before. It appears that LabVIEW also calls the Panel Resize and Pane Size events upon loading the front panel of a VI that hosts an XControl if those events are also configured in the Facade VI. This causes LabVIEW to mark the top level VI with a "dirty dot" indicating it needs to be resaved if the State Changed boolean of the Facade VI is set to true in that event. This means that each time the host VI is opened, the top level VI is marked with a dirty dot and the user is prompted to save the VI upon closing it.
The workaround:
Filter the Panel Resize event by comparing Old Bounds to New Bounds and if they are equal, skip execution of any code in the Panel Resize event.
I'm not 100% sure that this is what is occuring in your case but it certainly seems suspect, and is a known issue that has not been fixed yet.
03-29-2011 01:41 PM
@James D wrote:
Okay, it turns out the cpp issue I was running into was unrelated to your problem. However, I have found a different known issue than before. It appears that LabVIEW also calls the Panel Resize and Pane Size events upon loading the front panel of a VI that hosts an XControl if those events are also configured in the Facade VI. This causes LabVIEW to mark the top level VI with a "dirty dot" indicating it needs to be resaved if the State Changed boolean of the Facade VI is set to true in that event. This means that each time the host VI is opened, the top level VI is marked with a dirty dot and the user is prompted to save the VI upon closing it.
The workaround:
Filter the Panel Resize event by comparing Old Bounds to New Bounds and if they are equal, skip execution of any code in the Panel Resize event.
I'm not 100% sure that this is what is occuring in your case but it certainly seems suspect, and is a known issue that has not been fixed yet.
The Panel Resize event is firing (as well as the data change event) and when I add the workaround I mentioned earlier it stops opening dirty. However, I find it odd that it only marks the other facade vi dirty, but not any other VI it is on, or any other VI the top level xcontrol is on. That is to say, my issue seems inherently different than this issue I mentioned in my first post.