VI Refnum from subVI No Longer Valid when access via VI serve in an Exe

[LVAutomation]

Running Labview 2020 f1

I wrote a simple Task Manager that will launch VIs dynamically and retain a list of VI Names, VI Refnums and Status as an array of Clusters called OpenTasks on the Task Manager Front Panel.  I also wrote a test interface to access the the Task Manager OpenTasks Front Panel Control via AppRef->Task Manager VI Ref->OpenTasks ControlRef.  In my test interface, once I have the OpenTasks control ref from the Task Manager VI cast to more specific strict type of OpenTasks control and then obtain the VI Name and VI Refnum of the OpenTasks.  The test interface can obtain the Open Tasks VI refnum in this manner when the Task Manager is run in the Development Environment but returns "Refnum No Longer Valid" when the Task Manager is in an executable and the test interface obtains the Task Manager ref via TCP VI server. 

Below is a screenshot that shows the TestTCPAppServer.vi (running in the dev environment) accessing the SimpleTaskValidation.exe.  As you can see the VI refnum hex value is the same in both the executable and the TestTCPAppServer.vi but the probe shows the "Refnum No Longer Valid" and Not a Refnum returns true(ValidRef=False) in TestTCPAppServer.vi while returns false (ValidRefs?=True) in the executable.  I know that that TestTCPAppServer.vi is obtaining the OpenTasks control ref because the VI Name is returned correctly - only the VI refnum is No Longer Valid.  

Further Notes: the Exe Build Spec is has "Remove Front Panel" unchecked for everything in the build.

I attached a zip of the example project with Exes.

Can anyone explain why the VI refnum is "No Longer Valid" when accessing the Control via TCP VI server?  Anyone have any idea for work arounds here?  Any help is appreciated.

[GerdW · Accepted solution]

Hi LVAutomation,

Refnums are only valid inside their own context!

Each executable maintains its own context: when trying to access refnums read from other executables you will hit this "refnum is invalid" because Exe1 has no knowledge about the refnums of Exe2!

As long as you run all this inside the LabVIEW IDE the "overall" context will be LabVIEW itself, so each refnum is "known" to each VI inside the IDE context. Once you separate your code into several executables this is no longer valid…

[LVAutomation]

Thanks for your response here.

"Each executable maintains its own context: when trying to access refnums read from other executables you will hit this "refnum is invalid" because Exe1 has no knowledge about the refnums of Exe2!"

You must mean VI refnums and not Control refnums?? 

In the example code here, clearly I am able to access the Control Refnum to extract the VI Name and the VI ref hex value from the control across contexts.  I have other code not shared where Executable App A uses AppServer to Access Control Refnums in Executable App B and this works for at least all the Top Level VI Refnum and all Control Refnums in the Top Level VI in App B.

Can you point me to some Labview documentation that clearly defines the limits of refnum validity across the executable Contexts?    

[rolfk · Accepted solution]

As long as you access things through the VI interface by opening an application instance to the remote exe,  you open a connection to that application context and all refnums are proxied by VI server. But refnums you store in a global or LabVIEW Intelligent Global variable have no meaning in any other context. They are not part of the VI protocol and do not get proxied.

[LVAutomation]

Thanks for the clarity.  I think both answers here where the solution but Rolf, your answer provided the clarity I need here.

What I tested as a solution:

In the TestTCPAppAccess Open the App Reference->Open the Main VI Ref->Get the Task Manager VI ref->Open Task Control Ref->Get the Task VI Names->Open the Task VI refs by names within the TCPAppAccess Context and the VI refnums are valid along with all Task Control Refs! 

I have the Solution.

Thank you!

[billko]

FYI you can mark more than one post as a solution (or mark one as the solution and the other with a kudo).

[LVAutomation]

Done Thanks!