Cannot set control value by reference from LabVIEW

[loc.nguyen]

Hello all, 

today I ran into a problem with get and set control value by reference between LabVIEW and an LV-built application.

So I have this LV-built application which calls my other VIs (from another project/library) and displays their front panels within the application's UI. 

Now I want to control these called VI programmatically with LabVIEW. So far I can get the Application Refnum, called VI (loaded VI in memory) Refnum, and Controls Refnum without any problem. However, when I try to set the Control's value using the retrieved Control Refnum, nothing happens. 

With further effort to solve the problem, it appears to me that the loaded VI in the memory and the VI being executed by the application are 2 different instances of the same VI, as when I changed a control value from the application, I only get the default value of that control by reading using its Refnum. My VI is, however, set to fully reentrant (no memory sharing between instances). cause it is required by my end system.

Has anyone got this problem before or know sources that can point me to the solution?

Thank you all for reading.

[rolfk]

Show your code of how you do it in LabVIEW. The VI Server interface is quite large and has many options and if you try to control a VI in a LabVIEW executable, there are certain limitations in what VI methods and properties are available.

There are two possible reasons to that:

1) The VI Server method (and sometimes property) is not available in the runtime environment. This happens as the LabVIEW developers designate certain functionality to be only desirable in the editor version of LabVIEW and not in an executable. For one reason some things really do not make any sense in the runtime environment such as saving a VI as you can not modify it in an executable but sometimes it is also just a decision that a function simply is decided to not be available in the runtime as it may be seldom useful and all code not compiled into the runtime will reduce its size in comparison to the full development system.

2) Some VI server functionality is intentionally not available over a remote connection as it is considered to intrusive to allow a remote party to have access to it. 

Since your executable is a different process space, your LabVIEW system is a remote client to your executable (the connection actually happens over TCP/IP even if both your executable and LabVIEW run on the same machine) and may not be allowed to execute some properties and methods you try to access. But if you use proper error handling the according method and property nodes should return an according error message for such situations.

[loc.nguyen]

Hello Rolf,

Thank you for the fast response.

My VI is attached to this reply. Nothing complicated about it. It would be great if you can have a quick look, probably you can point me at which point I did wrong.

Thank you.

[rolfk]

The actual VI and according executable would help more.

[loc.nguyen]

Hello Rolf,

I am unfortunately not allowed to put the VIs and executable here. Sorry for that.

My VIs are basically an UI with buttons and their corresponding event handlers.

The executable is more complex as it is built with the idea to make the system distributed. However, the function that call these VIs is from the VI Server (Run VI method for VI class). I am also not suppose to modify the executable at all.

I know this is not much useful information. But thats all I could provide now.

[0Forest0]

It's happens because the button "mechanical action" property in not correct value. Not all mechanical actions allows you to set value of control by its reference!

And if you want to set control value use the labelText - better use "ControlValue\set" or "getControlIndexByName" method of that VI in invoke node.

[loc.nguyen]

Hello 0Forest0,

Could you be clearer on this, i.e. which mechanical actions allow me to set value by reference, and which does not?

Thank you!

[rolfk]

I believe all the latched options are not compatible to being set by the value property. You should get an according error from the prperty node. It at least errors when doing it locally.

And by the way you are leaking VI references. You only close the control refnum that you found to be your control, all others are left unclosed.

[0Forest0]

All mechanical actions begins whith "switch..." will work and actions begins whith "Latch..." will not.

And if you want to set control value use the labelText - better use "ControlValue\set" or "getControlIndexByName" method of that VI in invoke node.

[billko]

---

@0Forest0 wrote:

All mechanical actions begins whith "switch..." will work and actions begins whith "Latch..." will not.

And if you want to set control value use the labelText - better use "ControlValue\set" or "getControlIndexByName" method of that VI in invoke node.

---

Just to clarify this post a bit:

It's a bit more complicated than just changing the mechanical action.  You also have to think about the consequences of changing the behavior.

As for the suggested way of setting the control value, the main merit is that it makes it a bit more maintainable in that if the order of controls change, it won't break your code; if the label or data type changes, it probably (and thankfully) will.  It's not perfect, but I haven't found a more maintainable solution yet.