LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How To test ActiveX Ref for NULL?

I have an ActiveX ref that I only want to initialize when the VI is called the first time and keep it in memory until the app closes. The test to check Is Null always fails to see the ref is initialized already. How do I test an ActiveX ref for NULL?

A section of the VI that fails is attached. The red box shows the section of interest.
0 Kudos
Message 1 of 10
(6,788 Views)
Well, that's how you would normally do it, so I don't know why your test is failing. What version of LabVIEW are you using?

Other comments:
  • Your sequence frame is totally unnecessary. If you delete it the code will work exactly the same way.
  • Your local variables are totally unnecessary. Use wires!
See attached image for a simple refactoring. Much cleaner and easier to read, no? Smiley Wink I'm guessing you probably come from a text-based programming background. LabVIEW is a dataflow language, not a procedural language, so you have to program it differently.

To learn more about LabVIEW it is recommended that you go through the tutorial(s) and look over the material in the NI Developer Zone's Learning Center which provides links to other materials and other tutorials. You can also take the online courses for free.


Message Edited by smercurio_fc on 07-12-2008 09:23 AM
0 Kudos
Message 2 of 10
(6,765 Views)

Thanks  for your reply. I am still have trouble with the VI. I stubbed out a VI to demonstrate. I selected an ActiveX object that should be on you PC, but if it is not there you'll need to select a different one. Here is a JPG of the VI:

Attached is the actual VI

I was hoping I could add an integer indicator to display the value of the ActiveX ref but could not figure out how to do it. Can you tell me how I can add an indicator on the VI to show the value in a way similar to the probe?

 

0 Kudos
Message 3 of 10
(6,733 Views)
Is this an example of when it's not working, or when it's working? 'Cause everytime I run this VI it creates the reference, as expected. Other than the fact that the local variable serves no purpose, the VI seems OK to me.

Also, the numerical value of that reference wire is pretty meaningless, and won't tell you anything. Even if the refnum is "not a refnum", the numerical value will be non-zero since it has to be a location in memory for the "variable".
0 Kudos
Message 4 of 10
(6,730 Views)
The second time the VI runs the activex object is again created, even though it is already open. The VI never closes the ref. 
 
The purpose of the test for NULL is to reuse the activex ref for subsequent calls to the vi.
If I do not use the local var for the ref, the value for it is not saved for subsequent calls to the vi.
 
 
0 Kudos
Message 5 of 10
(6,728 Views)
You are not understanding how this works. When you run the VI by itself and the VI finishes the ActiveX reference is no longer valid because there is no longer any VI that is in memory and still running that is using that reference. The local variable has no bearing on this, and, I'll say now for the third time, is completely useless. To see this in operation take the VI you just posted, and wire up to connector pane and then call it twice in a row. You will see that on the first call the reference is null, but on the second it's not. That's because the top-level VI is still running, so LabVIEW see the reference is still being used.

Side-note: Based on my above statement you should not assume that references will be closed automatically. You should always close references explicitly.
Download All
0 Kudos
Message 6 of 10
(6,724 Views)
I assumed that the value for the ref was held in memory between calls to the VI. Just like a static var is used in C.
I was hoping to hide theref from the calling VI. To fix the problem I put the ref in the caller vi and wired it into this vi. This VI returns the new ref to the caller, which is wired into a local var for the ref.
This fixes the problem of keeping the ref open during the app, however, I can't hide the ref from the caller like i would like.
 
 
 
 
0 Kudos
Message 7 of 10
(6,708 Views)

@mefitzpatrick wrote:
I assumed that the value for the ref was held in memory between calls to the VI. Just like a static var is used in C.

LabVIEW is not C. Smiley Wink The equivalent of a static variable in LabVIEW is a global variable.


I was hoping to hide theref from the calling VI. To fix the problem I put the ref in the caller vi and wired it into this vi. This VI returns the new ref to the caller, which is wired into a local var for the ref.
This fixes the problem of keeping the ref open during the app, however, I can't hide the ref from the caller like i would like.

I still don't understand why you're insisting on using local variables.

0 Kudos
Message 8 of 10
(6,704 Views)


mefitzpatrick wrote:
I assumed that the value for the ref was held in memory between calls to the VI.

It is. It's just that once the top level VI goes idle the resource the reference is pointing to is garbage collected (although, as mentioned, this is not something you should rely on when working with an external resource like ActiveX).
 
What you actually want is an uninitialized shift register which will maintain its value between runs, just like your local, as long as the top level VI in the hierarchy it is in does not go idle. That means that if you run it by itself, it will do you no good.
 
 
You can find some more details about this technique here.

___________________
Try to take over the world!
0 Kudos
Message 9 of 10
(6,700 Views)

Hi,

You do have to hide the ref from the VI if you use shift registers as suggested in the last post. I assume you were trying to hide the ref because you did not want the VI to get a new value of the ref everytime it runs. However, with a shift register it passes the current  value of the ref at every iteration--therefore you should not be dealing with a new ref every time as the initial value will remain open. Hope this helps.

Ipshita C.

National Instruments
Applications Engineer
0 Kudos
Message 10 of 10
(6,677 Views)