Jump to content
The Q

Help get QControls added to LabVIEW Core

Recommended Posts

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 by smithd

Share this post


Link to post
Share on other sites
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 by ShaunR

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

image.png.d929b4a75374ef4cb504e43e4351b7c4.png

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).

Share this post


Link to post
Share on other sites
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 by shoneill

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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)

image.png.faf67b0b91fd37033882691141faead2.png

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.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.