Why is execution state = RUNNING?

[CoastalMaineBird]

I need to dynamically load several VIs.

Previously, the VIs had no wired connections, they did their inputs and outputs via a global mechanism.

The following code worked:

OPEN VI REFERENCE (given path to VI. TYPE SPECIFIER was unwired).
Use PROPERTY NODE to examine EXECUTION STATE.

If STATE was BAD, RUNNING, or RUNNING TOP LEVEL, warn user, and not allow execution.

If STATE was IDLE, store the refnum, and later call it (repeatedly) using the RUN method of INVOKE NODE, then close the reference.

That all worked fine.

Now, requirements have changed. I need to pass a string in to the dynamic VI. (I realize I could do it via the global mechanism, but that�s beside the point right now).

So I switched to a CALL BY R
EF. NODE approach.
To do that, you have to have a strictly-typed VI reference.
No problem, that�s actually good - if the user gives me a bogus VI, I can detect it.

Except...

Any VI I try, if it passes the OPEN REFERENCE error-free, gives me an EXECUTION STATE of RUNNING.

This makes my logic fail.

It is NOT actually running, I can verify that it has no callers, it�s not really busy.

Yet it tells me that it�s running.

This is on LV 7.0 - I went back to LV 6.1 - same thing.

The help for EXECUTION state says:
��Running means that the VI is reserved for execution...�

Is this expected behavior?

Do I need to change my logic to accept the RUNNING state and proceed?

[Mads]

Calling by reference is similar to a static call here;when the caller runs it has all the static sub-VIs and the open by reference VIs reserved for execution, i.e. running. Personally I would define "running" somewhat different...but that's how it works.

If you call it using the run method instead you can set the control value using the set control method, that works in built applications as well now.

[crelf]

Mads is right - "Running" means that the VI is either executing, or reserved for execution. Opening a reference to a VI sets its execution state to running. My approach is to have a Boolean on the front panel of the dynamically loaded VI, and dynamically set it to true or false, depending on what I want the calling VI to think. Although not strictly the same as a running execution state, I can signal when the VI enters a main execution loop or the like.

[CoastalMaineBird]

Personally I would define "running" somewhat different...but that's how it works.

That's what I had guessed, and further tests show that it seems to work OK, if I accept "running" as NOT a reason to stop the show.

I suppose it makes sense if you think of it as a substitute for a direct use of the subVI. By opening the reference, you are in effect placing that VI on the current block diagram, and therefore it's running as a child of the current VI.

Calling by reference is similar to a static call here;when the caller runs it has all the static sub-VIs and the open by reference VIs reserved for execution
--- But there's something missing from that explanation - the error occurs BEFORE the call-by-reference. I've OPENed the REF
ERENCE and examined a PROPERTY.

Apparently the fact that it's a STRICTLY-TYPED reference makes a difference in the value of the PROPERTY (EXEC state). I would expect this same behavior in both cases, but it's different.

[CoastalMaineBird]

If you call it using the run method instead you can set the control value using the set control method,

Do you know if that's faster / slower / what?
My hunch is that it would be slower, and I'm counting cycles here.

[CoastalMaineBird]

Opening a reference to a VI sets its execution state to running. 

But that's demonstrably not the case.
As I said, in my original post, opening a NON-STRICTLY TYPED reference to a VI results in an execution state of IDLE.

It is THIS difference that I tripped over.

[Mads]

What I wrote was: "when the caller runs it has all the static sub-VIs and the open by reference VIs reserved for execution"...

In other words; the call does not need to be made, the caller VI will check all potensial calls the instant it is run and reserve those sub-VIs for execution.

[CoastalMaineBird]

when the caller runs it has all the static sub-VIs and the open by reference VIs reserved for execution"
All I'm saying is that your statement is apparently ONLY true for STRICTLY-typed VI references - if the OPEN REFERENCE is a NON-STRICTLY typed reference, then the EXEC state is IDLE.

[crelf]

Fair enough - just trying to help...