Why can't I reuse the global automation refnum when it hasn't not been explicitly closed?

[Diskman]

I've stored an automation refnum to an ActiveX object in VB in the global vi. But the global refnum does not appear to be valid for calls with subsequent VIs other than the VI that created the refnum in the first place. I cannot use the open automation VI since it must be from the same instantiation of the object.

[Greg_McKaskle2]

> I've stored an automation refnum to an ActiveX object in VB in the
> global vi. But the global refnum does not appear to be valid for
> calls with subsequent VIs other than the VI that created the refnum in
> the first place. I cannot use the open automation VI since it must be
> from the same instantiation of the object.

LV automatically closes refnums when the VI that opens them goes idle.
If the VI that open them is statically linked in as part of the VI that
later needs the refnum, then the refnum will still be valid.

Greg McKaskle

[Diskman]

Greg,

How do you propose that the individual VIs be statically linked? Will passing the refnum from the output of one VI into the input of another be suffice? By the way, are there plans to alter the behavior of LV with respect to automation refnums in the future so that the connection can only be explicitly close? Otherwise, what's the point of having the "Close Automation" VI?

[Greg_McKaskle2]

> How do you propose that the individual VIs be statically linked? Will
> passing the refnum from the output of one VI into the input of another
> be suffice? By the way, are there plans to alter the behavior of LV
> with respect to automation refnums in the future so that the
> connection can only be explicitly close? Otherwise, what's the point
> of having the "Close Automation" VI?

Static linkage means that the subVI that opens the refnum is a part of
the hierarchy that uses it. Ideally, the linkage is there because you
call the subVI and return the refnum rather than storing it into a
global. You can also have a subVI call that never gets called because
it is in a case statement in a case that never gets run.

You didn't really m
ention what you are doing here. My guess is that you
are hand-running the open then hand-running the usage VIs. This direct
manipulation mode where all garbage collection is turned off would be
handy, but it would also require some way to do the collection since
many a VI is written such that it doesn't do a Close.

Close works the way you probably expect. It closes the refnum. If the
refnum isn't closed explicitly, then when the VI finishes, the refnum is
closed by LV. True, given enough memory, and assuming the VI will
someday finish, you don't absolutely need to call Close. Problem is, my
computer has a finite amount of memory, and I've heard of LV programs
running for several years. For these reasons, Close is provided, and it
is recommended that you close everything you open.

Greg McKaskle

[Diskman]

Greg,

What I have is a drive interface tool. The user chooses from a number of tasks to be performed. I chose to store the refnum in a global variable to minimize the number of input parameters needed for the individual tasks (VIs). An Init function was created to open the connection then store the refnum returned.

With regard to the close function, I think you've misunderstood me. I truly appreciate the value of it. I was simply being sarcastic since LV automatically closes the connection whether the user wants it to or not whenever the connection is idling. The programmer should decide how to handle the flow of his/her program NOT the programming language.

[Greg_McKaskle2]

> What I have is a drive interface tool. The user chooses from a number
> of tasks to be performed. I chose to store the refnum in a global
> variable to minimize the number of input parameters needed for the
> individual tasks (VIs). An Init function was created to open the
> connection then store the refnum returned.
>

From what I now understand, your VI is run again and again with
different settings. To keep in control, keep your VI executing by
placing a loop around it.


> With regard to the close function, I think you've misunderstood me. I
> truly appreciate the value of it. I was simply being sarcastic since
> LV automatically closes the connection whether the user wants it to or
> not whenever the connecti
on is idling. The programmer should decide
> how to handle the flow of his/her program NOT the programming
> language.

I suspected it might be sarcastic, but email makes it very hard to tell.
I agree that the programmer, or rather the program should be in
charge, but this is only true when the program is running. When the
program finishes, there isn't any code to tell LV what is supposed to
happen. To keep from using up connections and memory, LV frees
resources at this point.

Greg McKaskle