xcontrol container state uninit

[RVallieu]

I have created an Xcontrol and am using a functional global internal to keep track of the instances of the XControl invoked in my code.  This is done from within the Facade VI - since I know which events fire when the XControl is dropped, or the VI is just opened or closed.  I prevent duplicates from being added to the list.

I want to remove the refnum from the list of XControl when the XControl is removed - this works very nice usnig the Uninit.vi and taking the Refnum out of the Container State control.  I pass this refnum to my FG that maintains the list of refnums (converted to U32's). 

The problem I am having is that when the VI that contains an instance of an XControl is closed and the Uninit.vi is called the Refnum returned out of the Container State control is NOT the same (refnum is listed as invalid due to the owning VI being closed I suppose).  The thing is the refnum numeric value is also different.

• Is there some way to get the Uninit.vi Container State refnum to pass out the same refnum that was returned in the Facade VI when the owning VI is closed?

[RVallieu]

I found that if I add the control refnum to the Display State and set State Changed? to T in the Facade that the Refnum of the particular XControls gets pass properly to the Uninit.vi

However - I do not like the fact that the Owning VI then prompts me that a change has occured that requires the user to take action to either save or not save the VI.

[RVallieu]

I have found that the Refnum returned by Container State in the Init.VI is the same refnum as returned in the Container State of the Facade.vi

The only Ability VI that is causing trouble is the Uninit.vi - the refnum returned does not match numerically the other two, and the refnum returned is also "invalid".  I don't really care about the invalid part, I just want numerical matching.

I do not like having to go through the "unsaved changes" dialog box on close just to pass a refnum to the Display State control in the Uninit.vi

[BCho]

Hey Ryan,

It is a bit unclear what is going on here. Would it be possible to post an example of the Uninit.vi not working as well as one of the other vi's that you mention is working fine. This may shed a little more light onto what the actual issue is here.

-Ben

[RVallieu]

Create any Xcontrol you want.

The Container State in the Facade VI has a Refnum control in the cluster that returns the refnum to the XControl itself.

Open the Uninit.VI in the same XControl - you see the same Container State control - it has the same data type (porbably based on a Typedef) as the Container State in the Facade VI.  (You have to add the Uninit Ability first).

When the Uninit VI runs the refnum returned is not the same as the one returned in the Facade VI.

Message Edited by RVallieu on 04-22-2009 11:39 AM

[BCho]

Hey Ryan,

How are you passing the refnum out of the Facade VI and the Uninit VI, a global variable? Are you expecting the renum for that particular VI or thie calling VI? This Knowledgebase might help. Is this issue related to the one presented in this Forum Thread?

-Ben

[RVallieu]

Ben (BCho)

Sorry for the confusion. I am not passing out the refnum that is contained in the Container State that points to the XControl itself.  I am trying to utilize that reference within the XControl.  Whenever a new instance of the XControl is opened I add its refnum to a Functional Global list maintained only within the XControl.  The Uninit case runs when the XControl is being taken out of memory (Vi closes) - I was hoping to use the Container State refnum to remove the XControl Refnum from the FG list - but the Uninit VI does not get the same reference as Init.vi and the Facade.vi

The refnum from the Container State is never passed out of the XControl.

[RVallieu]

Sorry forgot to answer the other question:

No this is not the same issue as posted in the other thread.  It is the same XControl that I am working with, but a different issue.

I have read the KB article on obtaining a reference to the owning VI - but that is not what I am trying to do.

Message Edited by RVallieu on 04-24-2009 08:39 AM

[RVallieu]

OK here are some screen shots of what I am seeing.  Maybe this is the intended operation - I am not sure.

Facade VI returns Refnum to XControl when dropped, or a change to value is made, etc. - always gets the same refnum per XControl Instance.

Now the problem arises when the VI containing the XControl is closed - the Uninit case is called and the XControl allows you to close out any resources in this VI.

As you can see the Refnum to the XControl is not maintained.  I had expected this value to be available until the Uninit.vi finished execution.  The VI you see is the functional global where I was storing the references to the instances of the XControls.

One of my XControl Properties was to get back a count of the number of XControl instances being utilized.

Since the refnum is not maintained I can not cleanly clear my list of that one particular XControl refnum. 

The workaround I have found is to add the refnum from the Container State to the Display State and use that to pass it to the Uninit - but I really do not think this should be necessary - why is information carried through on the Display State and not the Container state when the Unit occurs?

The other thing I don't like about the work around is that it forces the "Save Changes?" dialog when closing VIs - this is unacceptable in most use cases since nothing has changed about the XControl that should warrant a Save Changes at least in the end users eyes.

Message Edited by RVallieu on 04-24-2009 09:31 AM

[RVallieu · Accepted solution]

Well I found a better workaround thanks to a discussion a coworker and I had.

I can check my list of XControl Refnums in the Uninit.vi and remove the invalid ones (simply asking for Class ID out of a property node or some other simple property read) and checking for Error out of the property node lets me know that the Refnum has gone invalid to that particular XControl (Owning VI has been removed from memory).

I think this will work out ok since the Uninit only returns a bad refnum when the XControl owning VI is removed from memory - if you simply delete the XControl from the VI FP the refnum is still valid.

I would still very much like to know if the dropped refnum is the expected behavior.