02-23-2015 01:10 PM
I'm trying to gain access to subpanel controls (in an executable) via VI server but it doesn't seem to be allowing me to get a valid reference to the inserted VI (1026: VI Reference is Invalid). If I use the exact same code in the executable itself, it works just fine.
Attached is the executable and the VI that I'm using to try and retrieve a reference to the subpanel's VI.
Any ideas why this is happening?
Solved! Go to Solution.
02-24-2015 12:13 AM
02-24-2015 10:17 AM
I'm currently in the process of reading your blogs about subpanels but in the mean time, here is the code snippet of my executable. At the bottom, in the conditional disable diagram, is the code that is in the VIServer_TestingSubpanels.vi.
I've tried both reentrant and non-reentrant settings for the subpanel. The subpanel in the attached executable above is reentrant.
02-27-2015 10:46 AM
After reading more on subpanels and reading your blog, I'm still unclear as to why I'm having an issue or what might be a method to work around the issue.
Maybe a little context will help:
The executables that I create will be manipulated by an external program created by another group within the company. So, what they have done is create a DLL that uses the VI server to access front panel controls and indicators from a LabVIEW-built application. This currently works just fine for anything that is on the main VI's front panel. But, what I am trying to do is create hardware specific subpanels for the controls that actually do the interfacing with the hardware. There are several different pieces of hardware with which we will interact, each having its own subpanel in the same main application. So, they need to be able to 1) find which VI is running in the subpanel programmatically and 2) interact with that subpanel via VI server within the DLL.
Any thoughts are definitely appreciated.
02-27-2015 01:08 PM
02-27-2015 01:49 PM - edited 02-27-2015 01:54 PM
@mikeporter wrote:
Ohhhh... That's easy.
There is a subpanel property that will return a reference to the VI that is currently in the subpanel. From that you can get the name of the VI and store it somewhere VI Server can find it -- like a FGV.
And that brings us back to the topic of this thread. The subpanel property is called "InsertedVI" and it always returns an invalid (but non-zero) reference when it's trying to access it from outside the executable. When I use the same code inside the exectuable, it works fine (see this image of the executable source code; the code in the conditional disable diagram is the code I'm using in the external VI where I'm getting the invalid reference which means I can't get any information about the subpanel's inserted VI) .
I can successfully get all the references to the main application's front panel which is how I am able to get the reference to the subpanel itself.
02-27-2015 04:13 PM
02-27-2015 04:35 PM - edited 02-27-2015 04:36 PM
Did you test my code that I posted along with the executable? I haven't been able to work on it since I posted so it's still current.
I don't see any race condition as long as I run the VIServer_TestingSubpanels VI while the executable is currently running (which is how I'm testing it) and there is only one subpanel VI (and there will only ever be one VI in the subpanel during execution in my context).
I am using LabVIEW 2013 SP1.
02-28-2015 08:44 AM
Ok, I see the problem, VI references are local to the instance of LabVIEW that generate them. When you read the VI reference, you are getting the correct numeric value (as shown by the fact that it is on-zero). However, in the development environment from which you are accessing the executable, the reference is not valid. That reference is only valid in the executable's envirnment. What you need to do in the executable is to get the name of the VI in the subpanel when you insert it and store that name in a FGV. Then from your remote application, read that FGV -- and you will have the VI name.
Mike...
03-02-2015 09:16 AM
Ok so basically, the two applications are "playing in two different sandboxes" which makes sense.
Thanks for your help Mike.