xcontrol problem in exe

[LarsM]

I have an xcontrol with a push button. When the button is pushed there's a check whether the vi is running or not. Problem is, when opening the vi as a built exe the xcontrol always says it is running, even if it's not!

What is going on?

[TWGomez]

More than likely it has something to do with the "check" to see if the VI is running. The path for the VI changes when it's rolled into an exe. You have to strip the program name out of the VI path when it's an executable.

If this isn't the case then provide some more information and a png and zip of the VIs if possible.

[tst]

The VI class property Exec.State returns the value Running not only when the VI is actually executing, but as long as it's not idle (meaning statically called by another VI which is running). Because in an executable the top level VI starts running automatically, all the VIs in its hierarchy are in the Running state.

I don't think there's a way to know whether a VI is actually running or not without adding special code to it, such as setting a flag when it starts running and unsetting it when it stops. XControls already do this, where you get a special flag in the XCtrl, but I'm assuming that's what you're already using and it shows you that the VI is running (because it's actually checking the State property of the VI).

In any case, you should be aware that even if you load the VI completely dynamically and it's not actually in the Running state before you explicitly run it, there are still many things which you can't change in an executable.

[altenbach]

---

@O.P. wrote:

... there's a check whether the vi is running or not...

---

What kind of "check" are you doing? Please be much more detailed!

What is the use of a non-running state in an executable? Can you explain?

[LarsM]

I have an XControl with an event for a push button:

If I drop the control in a VI and press the button, I get:

If I build an exe and start it, pushing the button yields:

Thing is, I haven't started the VI yet!

[tst]

I guess the XCtrl data always shows that in an EXE because it assumes the VI is always running, even though the white arrow indicates it should be in the Idle state.

In any case, what's your actual use case for this? It's unusual to have an idle VI in an executable. Normally, the UI shown to the end user should always have running VIs and never show the toolbar.

[altenbach · Accepted solution]

"Run mode?" is not the same as running. You can switch a VI to run mode using ctrl+m in which case the VI can no longer be edited, but it is still not necessarily running.

After building an executable, a VI can no longer be in edit mode, thus it is always in run mode, running or not.

[AlexanderKhodarev]

There are couple of properties you can read to determine

1) if you are now in executable or development mode (App.Kind)

2) if you are running or not (Exec.State)

(screenshots attached)

[LarsM]

---

@tst wrote:

I guess the XCtrl data always shows that in an EXE because it assumes the VI is always running, even though the white arrow indicates it should be in the Idle state.

In any case, what's your actual use case for this? It's unusual to have an idle VI in an executable. Normally, the UI shown to the end user should always have running VIs and never show the toolbar.

---

So how do I keep a built VI running? Is there a way to make en exe run continuously?

[tst]

---

@O.P. wrote:

So how do I keep a built VI running? Is there a way to make en exe run continuously?

---

You put a while loop (with a wait to avoid 100% CPU consumption) around the code which you want to run repeatedly and use an appropriate stop condition.

Run Continuously is not something which should be used in any serious program. It's fine if you want to test something quickly or maybe if you're playing in the IDE and need to change something all the time, but it doesn't belong in real programs (even if they're running inside LV). Just like Word and Excel don't show you all kinds of panels and require you to run them, so should your programs not require it of your users.