How to programmatically determine if vi started with Run button

[TeraTech]

I would like to programmatically determine if a VI was started because someone clicked the Run button or if it was called from another vi. I was using the Call Chain function and checking if the size of the array = 1.  This generally works except for one caveat - if the VI is dynamically loaded, the Call Chain will also = 1.

There is a IsRunningInteractively property but that doesn't seem to work. Regardless if I click run or call the subvi from another vi, the IsRunningInteractively is false.

I am using LabVIEW 2017

Thanks!

[wiebe@CARYA]

I don't know of any way to distinguish between a VI started by the user or dynamically. EDIT quite sure there isn't.

If the VI runs as a subVI, it's state will be 'running', if it's started dynamically or by the user it will be 'running top level'.

The help of IsRunningInteractively mentions it returns the state of the VI on 'the target device', suggesting it involves RT.

Why would you want to know this?

I'm sure there are solutions to avoid the need for this, but in general there's no way to do this.

[BertMcMahan]

I don't know of a direct way to solve this issue, but I'd like to know what you're really after as well.

Total stab in the dark here, but are you trying to distinguish between a VI running in the dev environment and one running as an application? If so there are easy ways to determine that.

[paul_cardinale]

Have a terminal on connector pane set to "Required".  Set the default value of the corresponding control to something that will never* be sent from a caller.  When the VI runs, check if the value is the default.

Not absolutely foolproof, but you should be able to make it work.

* For example, use a NaN for a floating point number, or maybe \FF\FF\FF\FF\FF\FF for a string.

[paul_cardinale]

This works but it is super klunky and not robust (It could break if NI makes a slight change to the toolbar style).

[JÞB]

---

wiebe@CARYA wrote:

The help of IsRunningInteractively mentions it returns the state of the VI on 'the target device', suggesting it involves RT.

---

Actually,  IsRunningInteractivly has more to do with debugging like step into, run continuously,  breakpoints etc and remote debugging sessions if I remember correctly.  Not something I play with since, I stopped writing bugs.:D

Thinking outside the box.   ...if the user presses the run Arrow there is likely a user around somewhere nearby.   You could try a dialog and ask.  Definitely not foolproof!

I'd go looking for a different question to ask!  Exactly WHY are you looking at this?  That might suggest a more robust approach to get what you need. 

[TeraTech]

I've always been confused by how the LV documentation uses the term "target" since, at least from my perspective, a PC can also be a deployment target. Thanks for chiming in on that.

Why would I want to know this?
Sorry, I forgot to mention my need... First, I know that I can distinguish a vi running in an exe from development with the Application:Kind property. That is not what I was searching for.

I basically need it for standalone testing of a vi. I have a very "modular" application with many "sub systems". After writing a new vi or modifying an existing vi, I often want to test it without launching my entire application then have to run it trough its paces just to get to a test scenario in place for that vi. In the edit mode I am able to run (run button) various top-level module vis (subset of all the modules in the application) to produce data, then run (run button) the vi I want to test to consume the data for testing and debugging.

@Paul- The Execution:State is a good idea and cleaner that using Call Chain and the checking array size, but it seems to suffer the the same issue - not being able to distinquish running standalone (run button) vs being loaded and run dynamically.

I realize I can throw together a quick and dirty test project with only the modules I need, but being able to just run the modules, then run my vi-under-test is much simpler and quicker. It's also more convenient to leave my supporting modules running start and stop the vi I am working on.

I could also simply add a front panel Boolean called Test Standalone and check it in the code vs calling Call Chain... but then I have to remember to un-click it when I finally do run my entire system.... which I have done numerous times and have to shut down my app and restart.

As mentioned the Call Chain function work great (as would the Execution:State property), unless the vi under test is loaded dynamically. So perhaps another way to state the question, is there a way tell if a vi was dynamically loaded?

[paul_cardinale]

---

@TeraTech wrote:

I've always been confused by how the LV documentation uses the term "target" since, at least from my perspective, a PC can also be a deployment target. Thanks for chiming in on that.

Why would I want to know this?
Sorry, I forgot to mention my need... First, I know that I can distinguish a vi running in an exe from development with the Application:Kind property. That is not what I was searching for.

I basically need it for standalone testing of a vi. I have a very "modular" application with many "sub systems". After writing a new vi or modifying an existing vi, I often want to test it without launching my entire application then have to run it trough its paces just to get to a test scenario in place for that vi. In the edit mode I am able to run (run button) various top-level module vis (subset of all the modules in the application) to produce data, then run (run button) the vi I want to test to consume the data for testing and debugging.

@Paul- The Execution:State is a good idea and cleaner that using Call Chain and the checking array size, but it seems to suffer the the same issue - not being able to distinquish running standalone (run button) vs being loaded and run dynamically.

I realize I can throw together a quick and dirty test project with only the modules I need, but being able to just run the modules, then run my vi-under-test is much simpler and quicker. It's also more convenient to leave my supporting modules running start and stop the vi I am working on.

I could also simply add a front panel Boolean called Test Standalone and check it in the code vs calling Call Chain... but then I have to remember to un-click it when I finally do run my entire system.... which I have done numerous times and have to shut down my app and restart.

As mentioned the Call Chain function work great (as would the Execution:State property), unless the vi under test is loaded dynamically. So perhaps another way to state the question, is there a way tell if a vi was dynamically loaded?

---

Did you try "True Run State"?

[wiebe@CARYA]

---

@paul_cardinale wrote:

---

@TeraTech wrote:

I've always been confused by how the LV documentation uses the term "target" since, at least from my perspective, a PC can also be a deployment target. Thanks for chiming in on that.

Why would I want to know this?
Sorry, I forgot to mention my need... First, I know that I can distinguish a vi running in an exe from development with the Application:Kind property. That is not what I was searching for.

I basically need it for standalone testing of a vi. I have a very "modular" application with many "sub systems". After writing a new vi or modifying an existing vi, I often want to test it without launching my entire application then have to run it trough its paces just to get to a test scenario in place for that vi. In the edit mode I am able to run (run button) various top-level module vis (subset of all the modules in the application) to produce data, then run (run button) the vi I want to test to consume the data for testing and debugging.

@Paul- The Execution:State is a good idea and cleaner that using Call Chain and the checking array size, but it seems to suffer the the same issue - not being able to distinquish running standalone (run button) vs being loaded and run dynamically.

I realize I can throw together a quick and dirty test project with only the modules I need, but being able to just run the modules, then run my vi-under-test is much simpler and quicker. It's also more convenient to leave my supporting modules running start and stop the vi I am working on.

I could also simply add a front panel Boolean called Test Standalone and check it in the code vs calling Call Chain... but then I have to remember to un-click it when I finally do run my entire system.... which I have done numerous times and have to shut down my app and restart.

As mentioned the Call Chain function work great (as would the Execution:State property), unless the vi under test is loaded dynamically. So perhaps another way to state the question, is there a way tell if a vi was dynamically loaded?

---

Did you try "True Run State"?

---

VI don't need to show the toolbar while running.

It also doesn't distinguish between starting the VI manually, and starting it dynamically, which is the point.

[wiebe@CARYA]

---

@TeraTech wrote:

I basically need it for standalone testing of a vi. I have a very "modular" application with many "sub systems". After writing a new vi or modifying an existing vi, I often want to test it without launching my entire application then have to run it trough its paces just to get to a test scenario in place for that vi. In the edit mode I am able to run (run button) various top-level module vis (subset of all the modules in the application) to produce data, then run (run button) the vi I want to test to consume the data for testing and debugging.

---

So the way you call it is different?

Why not call it with the same preconditions as in the application?

Everything the application does can be done by the test... You'd basically make a test harness for the DUT (device under test, VI in this case). It's weird to me to do that in the DUT. Also, if you require preconditions, you can probably test them and for instance initialize the resources if they are not initialized.