More XControl questions / issues

[elset191]

XControl 1, X1, has two other XControls, X2 and X3, on its block diagram

When I open a VI with X1 on it, the Init ability is called for X2 and X3 three times each.  X1’s Init ability is called one time.  (The other VIs you see pop up are called from X2 and X3 as a result of Init executing, so they illustrate the Init calls.  They close when Uninit is called, and you can see as much when you close the VI and project)

When I close said VI, the Uninit ability is called for X1 and called twice for X2 and X3.  This, of course, leaves one instance of X2 and X3 left open.  Consequently, references and VI’s I opened as a result of the Init call are left open (you notice the two subvi's still open). 

Once I close the project, the Uninit abilities are called for X2 and X3, closing the remaining resources.

There is a file in the folder called log.txt I write to in the init and Uninit abilities for each XControl.  If you open it after each step you can see what I’m talking about.

Additional things:  After I close the VI, but not the project, X2 and X3 are of course locked.  When I right click “Unlock this library for Editing”, LabVIEW crashes with a .cpp error.  http://forums.ni.com/t5/LabVIEW/Error-when-I-Unlock-Library-for-Editing-with-XControl/m-p/1009044#M4...

My real project loads the XControls (and executes the Init ability) as soon as it opens for some reason, and makes it nearly impossible to edit them unless I close and open the XControls individually, due to the .cpp error above.

Questions

Is it expected that an XControl an another XControl should be called more than once?

Why don't they get unloaded when the main XControl is closed and unloaded?

Why the .cpp error?

[Greg_S-Video]

Hello elset191

I hope you are well.  I wanted to inform you that I tried to reproduce this behaviour in LabVIEW 2010 SP1 and I did not receive the error.  Regardless, I am going to file and corrective action request so that this is documented. For some reason, I was not able to reproduce the behaviour in LabVIEW 8.6.1 as my options were different when right-clicking the X controls in the project.

If you are interested in validating this for yourself, you may be interested in downloading a copy of our evaluation version of LabVIEW 2010 SP1.  Please see the following link for that option:

NI LabVIEW 2010 Service Pack 1 Development System

http://digital.ni.com/src.nsf/websearch/D7E7157873E230FA86257880005141FA?OpenDocument&node=node=2030...

Thank you very much for your effort in reporting this.  I think that video is amazing!  Which software did you use to create that?

I will be in touch shortly with the reference number.

[elset191]

Thanks for looking into it, I appreciate it.

The video was created using Wink.  Several other people on the forums use Jing, but it crashes on me every time I try to record a video.

[Greg_S-Video]

Hello elset191

Here is the Corrective Action Request that references your issue.  I have included you as a customer whom this problem is affecting.

Request #: 302463

Description: XControls remain open after corresponding VI is closed and crash occurs, XControl cpp error in LabVIEW 8.6.1f1 (Fatal Internal Error: "ThEvent.cpp", line 184)

I'm sorry that this has been a frustration to you.  The fastest way to resolve this issue appears to upgrade.  Have you attempted to reproduce this error in LabVIEW 2010 SP1?  I was unable to reproduce this situation in LabVIEW 2010 SP1.

The CPP error is due to some issue with how this has been internally developed.  It appears to have been resolved in LabVIEW 2010 SP1 as do the other issues you have been dealing with.  Can you please confirm this for me?  I am happy to further address this issue to ensure your success.  All the best!

P.S.  I have provided a link to the LabVIEW 8.6 Help simply for competeness.

Editing XControls that are in Use

http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/editing_xcontrols_in_use/

[elset191]

I'll try to do the 2010 test sometime this week when I have some down time.

[Greg_S-Video]

Hello Tim

Thank you very much for the update.

I eagerly await your results!

Thank you for choosing National Instruments!

[elset191]

---

@elset191 wrote:

I'll try to do the 2010 test sometime this week when I have some down time.

---

By "sometime this week" I meant, "in the next 3 months"

I ran my demo in the LV2011 Evaluation.  Everything behaved pretty much the same, except for I haven't (yet?) been able to reproduce the .cpp Error.

Is there an explanation as to why 3 instances of X2 and X3 are needed (not needed perhaps, but opened nonetheless) to operate Test.vi?  If I put breakpoints on the Facade three of them open as soon as Test.vi is opened.  If I proceed to operate within Test.vi only one of the facades answers to the changes, but the other two are still in memory. You can see this, for example, if you add a Mouse Down event in the XControl and put a break point in it.  You can see this also in the original video from the popup windows.

[Greg_S-Video]

Hello elset191

Thank you very much for getting back in touch with us!

I will look into this matter for you.  Any chance you would mind creating another Wink video showing us the behaviour you are seeing with the Mouse Down Event?  That was incredibly helpful the first time.  Thanks again!

[elset191]

I tried adding annotations to the video, but didn't figure out how to make them last more than one frame, so I'll put the rundown here.

As soon as Test.vi is opened from the project manager you can see three instances of X3 open.  This is because I put a breakpoint outside the main loop. Then, when I click on the intensity graph (i.e., the facade of X3) the Mouse Down event fires, to which only one of the X3 Facade instances responds.

X2 and X3 have the same behavior in this regard.

Why the extra two instances?

[Greg_S-Video]

Hello elset191

Thank you very much for getting back to me on this issue.  This issue will take me some time so in the mean time your patience is much apprecited.

Thanks again!

Sincerely,

Greg S.