Close ActiveX Reference after Type Conversion

[C.D.]

Hi,

I'm not profound experienced with ActiveX background mechanism. But I know that's importand to close every ActiveX reference to have open before.

My special case is shown in attachment. Is it necessary to close the origin and the converted reference? Thak you.

Kind regards

Christian

[~jiggawax~]

I think you are ok just closing the converted one.  Because if you think about it:

A close is just dereferencing memory space so that TestStand no longer claims it.

A typecast, like you are doing, is simply changing a certain memory space to be a different type.  And technically in this case it isn't doing that.  It is just making it so that you can access the right property and invoke nodes.  The value on the wire is the same.  I believe the object is the same too.  You are just tagging the wire as a specific class.

Summary: the memory space is still the same and only needs to be closed once.  If you probe the wires you should see the same value go into and out of the conversion.  That will for sure tell you that you only need to close it once.

My 2 cents,

[dug9000]

I'm pretty sure you need to close both (though I'm not a labview expert). That type conversion node is likely doing a QueryInterface which will add an additional reference to the underlying object. You should be able to determine this using teststand's normal leak reporting code. When the engine shuts down, teststand will typically display a dialog listing any propertyobject leaks that exist at that time. If you don't close both, I suspect you will see a leak get reported.

Hope this helps,

-Doug

[rolfk]

---

@dug9000 wrote:

I'm pretty sure you need to close both (though I'm not a labview expert). That type conversion node is likely doing a QueryInterface which will add an additional reference to the underlying object.

---

This is almost certainly true. ActiveX references work a little different than LabVIEW references. While you can "Typecast" LabVIEW references as long as they are compatible to the desired output class and they will indeed simply stay the same reference as far as the object underneath is concerned ActiveX has a strict reference count system that requires always to go through the QueryInterface() function if you want to change into a different class type. The returned interface can be simply an (ActiveX internally typecasted, really multiple inheritance) interface pointer to the same object or it can be an entirely new object embedded inside the compositing object. In both cases the reference count will be incremented for the underlaying object and that means you have to call the Release() method on that returned interface pointer to make sure you don't leak an object. Close Reference in LabVIEW will call the Release() method on the interface for ActiveX refnums (and also release the additional LabVIEW resources to manage the refnum).

There is a small possibility that the Variant To Data function does internally a Release() for the incoming refnum after it has done QueryInterface() for the new interface but I somehow doubt it. It should be easily testable since if that would be the case, the second Close Reference should return an error.

And just to make you feel a bit better, improper reference count handling in ActiveX is just about the single most error happening there, both when using ActiveX and especially when implementing an ActiveX component.

[jsiegel]

See this post for an explanation of this issue.  At least until LabVIEW 2014, you definitely needed to close the reference both before and after the conversion.  Unfortunately if your reference input to the Variant to Data function is actually a LabVIEW variant wire, the Close function won't work (it doesn't work on the variant data type).  The post gives a workaround for versions of LabVIEW prior to LabVIEW 2014; but it says the problem has been fixed in LabVIEW 2014.  I don't know if that means that in LabVIEW 2014, the Variant to Data function no longer increments the reference count and it is safe to only close the converted reference, or if it applies only to variants converted to a reference.  Perhaps someone from NI can clarify?

[rolfk]

I think you still should try to close both even in LabVIEW 2014. It's simply how ActiveX refcounting works. And the issue you reference wasn't the problem here, since he does get back a real refnum. How they solved it I'm not sure. May have made sure that the ActiveX interface is smarter in returning the actual datatype rather than just a variant in such cases. Or the Variant to Data does a Release() for refnum inputs. Hard to say.

[dug9000]

---

@jsiegel wrote:

See this post for an explanation of this issue.  At least until LabVIEW 2014, you definitely needed to close the reference both before and after the conversion.  Unfortunately if your reference input to the Variant to Data function is actually a LabVIEW variant wire, the Close function won't work (it doesn't work on the variant data type).  The post gives a workaround for versions of LabVIEW prior to LabVIEW 2014; but it says the problem has been fixed in LabVIEW 2014.  I don't know if that means that in LabVIEW 2014, the Variant to Data function no longer increments the reference count and it is safe to only close the converted reference, or if it applies only to variants converted to a reference.  Perhaps someone from NI can clarify?

---

That was a different issue that only applies to variants. I think LabVIEW was unnecesarily adding a reference to the interface contained in the variant in that case. In the case where both the original and target type are COM interfaces you should be closing both. I think the fix in LabVIEW 2014 is that you no longer need the sub-VI to ensure the reference added by labview when processing the variant is released, you can instead directly convert the variant to an interface without leaking a reference due to the variant.

Hope this helps,

-Doug

[jsiegel]

I have to admit that I don't have much deep knowledge of how ActiveX works, but I still don't understand the difference between the two cases.  Even embedded in a variant wire, there is still a reference there that (I think) may be cast to a different reference type, just like in the original example.  It seems to me that the behavior would have to be the same, namely that an additional reference would be created (or not).  It's not obvious to me that the Variant to Data function "directly converts the variant to an interface" and differently than it converts one interface to another.

[dug9000]

---

@jsiegel wrote:

I have to admit that I don't have much deep knowledge of how ActiveX works, but I still don't understand the difference between the two cases.  Even embedded in a variant wire, there is still a reference there that (I think) may be cast to a different reference type, just like in the original example.  It seems to me that the behavior would have to be the same, namely that an additional reference would be created (or not).  It's not obvious to me that the Variant to Data function "directly converts the variant to an interface" and differently than it converts one interface to another.

---

The difference is that there was an issue in labview where: "variants cannot be closed explicitly, and will not be freed until the VI leaves memory". I agree it would have made more sense if either LabVIEW had a way to close/clear variants, or if labview automatically handled COM reference releasing rather than requiring explicit close nodes like it does now. I'm not sure why things are the way they are in LabVIEW. Perhaps someone on the LabVIEW forums could explain.

That said, I think the image in that web page you posted is misleading. The fix doesn't really allow you to remove that close, what it does is allow you to remove the sub-VI altogether and just directly convert the variant to the COM interface. That image is to illustrate how you need to add that close when using the workaround, NOT that you can remove that when upgrading to a fixed version of LabVIEW. It's just trying to make sure that you are aware that that close is necessary, the close itself isn't the workaround for the variant issue, the dynamically called sub-VI is the workaround for that.

-Doug

[jsiegel]

I agree that the web page I referred to is just a workaround to what was a limitation of LabVIEW--I was just trying to answer the original question by illustrating the point that it is in fact necessary to close both the original and converted reference.

But what is still unclear to me now is that with the change in LabVIEW 2014, is it still necessary to close the original input reference (green wire) to the Variant to Data function?  In other words, does the new and improved Variant to Data function automatically close *all* input references (green wires as well as variant wires), or only references that are in a variant wire?