Enqueue in another VI using Application/VI Referencing?

[billko]

---

@JCoder wrote:

Hello,

I am exploring the possibility of being able to inject into another LabVIEW application from another to extend functionality of an application we do not want to modify. The main application is a producer/consumer state machine where the 2nd application simply needs to be able to shutdown the main application by either switching an existing boolean to true, or by adding the stop command to its message queue.

From what I've tried so far it seems you cannot change the property value of a boolean through the application/vi property nodes when the boolean is a latching mechanical button so my next idea was to try and add a stop command to the main application's queue, however, I can't seem to find much information on doing this so maybe it's not possible.

If anyone has any ideas on how to either get around changing the main application's boolean value or adding to its queue that'd be greatly appreciated.

---

The method I use is to change it to "switch when released" and then change the value to FALSE in the event that handles the button press so it becomes "unpressed". That will mimic the latching functionality.

Edit: Oops, I didn't address the part about "another application".

[paul_a_cardinale]

It might be possible.  You need to setup a port for your main app.  That might be as simple as adding a line to the .ini file for the compiled app (possibly something like "port = 1234"); but I don't really remember, you'll have to dig into that.

Then on your other app (that wants to communicate with the main app), use the function "Open Application Reference" (passing the port number to it).  Once you have that reference, use the function "Open VI Reference" (passing to it, the app ref and the name of the VI (you could specify the path inside the .exe, but it will be simpler to just use a string containing the VI's name)).  Now that you have the VI reference, you can rummage around and mess with stuff.

Note that there's most likely no block diagram, so you can only mess with the front panel.

[Gregory]

---

@JCoder wrote:

A couple of these solutions involve making a modification to the main application, which can't be done.

@GerdW, could you elaborate more on your solution please?

Thanks for the responses.

---

You would have to change your main application if it's not already "listening" for inputs coming from somewhere else. Barring that, you could do something very hacky like having your software take over the mouse pointer and clicking on the main application, but that seems like a very fragile way to solve your problem.

[avogadro5]

Here's an older post about this: https://forums.ni.com/t5/LabVIEW/How-to-use-User-Events-and-Queues-between-Executables/m-p/4395217#M...

If you have a VI server reference to another application (with permissive permissions set in its ini) you can open a VI from disk in that application and that VI will be able to interact with refnums in that application's context.

You can backdoor any code you want into any exe by editing the ini.

[Yamaeda]

---

@Gregory wrote:

---

@JCoder wrote:

A couple of these solutions involve making a modification to the main application, which can't be done.

@GerdW, could you elaborate more on your solution please?

Thanks for the responses.

---

You would have to change your main application if it's not already "listening" for inputs coming from somewhere else. Barring that, you could do something very hacky like having your software take over the mouse pointer and clicking on the main application, but that seems like a very fragile way to solve your problem.

---

Yeah, but if the original application can't be changed i don't really see any other solution. As it's described it's basically the definition of a virus.

[JCoder]

---

@avogadro5 wrote:

Here's an older post about this: https://forums.ni.com/t5/LabVIEW/How-to-use-User-Events-and-Queues-between-Executables/m-p/4395217#M...

If you have a VI server reference to another application (with permissive permissions set in its ini) you can open a VI from disk in that application and that VI will be able to interact with refnums in that application's context.

You can backdoor any code you want into any exe by editing the ini.

---

Thanks, I've been attempting to put it into my context. From your example:

Could I simply change the static VI reference to a VI in the main application that I want to access, and from there it would load from disk to the VI server. And if so, do the references need to be assigned to terminals in the main application/build?

[avogadro5]

---

Could I simply change the static VI reference to a VI in the main application that I want to access, and from there it would load from disk to the VI server.

---

Kind of, if you want to open a reference to a VI that's already included in the exe you should probably do it by name not path because VIs included in built applications have paths that are difficult to predict. You only need to load VIs by path if they aren't already loaded in the app instance.

---

And if so, do the references need to be assigned to terminals in the main application/build?

---

Not exactly, the VI you're calling in the remote app needs some way to access the refnums you want to interact with. It's difficult to say what might work because it depends on how your app is architected, where the more best practices the app follows the harder it is.

For example, if you're using DQMH it is extremely easy because you can just call the public API and take advantage of the fact that DQMH modules are globally accessible: the remote caller has no need to access an actual local refnum. If you're using actor framework it's intentionally very difficult and you'd need to cheat by, for instance, finding a lingering copy of an initialized actor value inside a front panel control.

If you're using neither some options might be to exploit any globals being used like FGVs or named queues you know the name of.

[JCoder]

---

@avogadro5 wrote:

---

If you're using neither some options might be to exploit any globals being used like FGVs or named queues you know the name of.

---

This is what I am attempting to do, I have a named queue inside the VI I want to "inject" so know that, let's say for example it's called "MainQ". All I want to do is inject a message, let's say "pause", into that queue so that it's actioned by the consumer loop.

[avogadro5 · Accepted solution]

---

@JCoder wrote:
This is what I am attempting to do, I have a named queue inside the VI I want to "inject" so know that, let's say for example it's called "MainQ". All I want to do is inject a message, let's say "pause", into that queue so that it's actioned by the consumer loop.

---

Right so you should call a VI that executes in the remote app that just opens a reference to that named queue and enqueues the message. I modified my old user event-based example to be named queue-based.

[paul_a_cardinale]

---

@JCoder wrote:

---

@avogadro5 wrote:

---

If you're using neither some options might be to exploit any globals being used like FGVs or named queues you know the name of.

---

This is what I am attempting to do, I have a named queue inside the VI I want to "inject" so know that, let's say for example it's called "MainQ". All I want to do is inject a message, let's say "pause", into that queue so that it's actioned by the consumer loop.

---

The tricky part (and maybe impossible), is to get the reference to the queue.  If the queue reference is present in a control or indicator in some VI, then, after that VI has run, you could read the value of that control/indicator.  If the queue reference is never exposed on any front panel, then you'll never be able to access it.