Help get QControls added to LabVIEW Core

[smithd]

16 hours ago, Aristos Queue said:

You can create GUIDs on any LV OS using:

LabVIEW 2017\resource\Framework\Providers\API\mxLvGenerateGuid.vi

 

thats quite the hidden gem🎅

16 hours ago, Aristos Queue said:

I have a long list of lessons I hope NXG learns. 

🦄

Edited April 22, 2019 by smithd

[ShaunR]

13 hours ago, Aristos Queue said:

So load it using Open VI Reference (without the flag) and the problem of being prompted to save should go away. 

It is loaded with Open VI Reference.

The Explain Changes" dialogue states that it is a cosmetic change (A front panel object was resized). My current suspicion is that it is linked to the  "Fit Control to Pane" setting of the xcontrol on the host VI and/or the facade (which the actual control is also set to). I've at least now ascertained that it also happens in normal sub-panels too and is repeatable.

Maybe I should just publish it with a known issue - something I have always hated to do. Then at least others can fiddle with it.

Edited April 22, 2019 by ShaunR

[Aristos Queue]

If you open it with Open VI Ref and then close it before calling Close Reference, there shouldn't be a Save Changes dialog. The only way I replicate is if I leave the panel open after the VI finishes running and then the user closes that panel (which is correct behavior). Is that what you're doing?

[ShaunR]

1 hour ago, Aristos Queue said:

The only way I replicate is if I leave the panel open after the VI finishes running and then the user closes that panel (which is correct behavior). Is that what you're doing?

This is a test harness I'm using.

It is the VI loaded into the sub-panel (Example1.vi) that invokes the save dialogue when this VI (Example2.vi) finshes executing. It also happens if the the  Abort VI button on the toolbar is pressed.

(auto dispose ref = true makes no difference if that's a criteria).

[shoneill]

On 4/19/2019 at 11:26 AM, gb119 said:

XControls are a bit of a pig, on that I guess everyone can agree....

But which bit? Some bits are actually quite tasty..... 🥓

Edited April 23, 2019 by shoneill

[Aristos Queue]

On 4/23/2019 at 1:43 AM, ShaunR said:

It is the VI loaded into the sub-panel (Example1.vi) that invokes the save dialogue when this VI (Example2.vi) finshes executing. It also happens if the the  Abort VI button on the toolbar is pressed.

That is really weird. 

I haven't tried to replicate... not sure I'll have time for a while... but there's one odd thing to try... after the "Remove VI" call, try adding a "Wait MS" of about 100 milliseconds. I'm trying to come up with hypotheses that would cause this problem, and the only one I can think of is that the subpanel is opening its own reference to hold the panel in memory and that is (for some unknown reason) flagged to show the Save Changes dialog. 

I'm torn between hoping this works you around the bug and hoping that it has nothing to do with it. 

[ShaunR]

On 4/23/2019 at 7:43 AM, ShaunR said:

This is a test harness I'm using.

It is the VI loaded into the sub-panel (Example1.vi) that invokes the save dialogue when this VI (Example2.vi) finshes executing. It also happens if the the  Abort VI button on the toolbar is pressed.

(auto dispose ref = true makes no difference if that's a criteria).

AQ has been looking into this for me offline (Thanks AQ) and managed to replicate the issue I was seeing. Addig a delay resolves the issue (which I plan to put in the known issues since it cannot be resolved internally in the xControl)

AQs explanation of what is happening:

Quote

 

What's happening is that the Abort is calling the transition code on the XControl, to shift it from run mode to edit mode, and when that finishes, it releases its internal references on the XControl's host VI. If that's not the last reference, it goes on. If it is the last reference, then it allows the VI to leave memory -- and the internal reference is opened with the flag that says to prompt for changes.

The Abort VI call is async -- it tells the VI to abort but it doesn't wait around for that abort to be finished. In this case, that means that the Close Reference happens first (and doesn't do anything because there's still an open ref from the XControl), and then the Abort gets done, and it does close. With the delay, those operations are reversed.

 

He also said that the problem goes away if source code is separated from the VI (not available in 2009).

So. I'll do some more testing and then release the xControl.