How was this button created? (see code below)

[GRCK5000]

In the code below. The button (Run this VI) is used to run the VI rather than the run arrow on the menu bar.

I found this code online. Kudos to Mr. Altenbach! If someone can tell me how this is created, I would appreciate it. 

[Andrey_Dmitriev · Accepted solution]

---

@GRCK5000 wrote:

In the code below. The button (Run this VI) is used to run the VI rather than the run arrow on the menu bar.

I found this code online. Kudos to Mr. Altenbach! If someone can tell me how this is created, I would appreciate it. 

---

It is a XControl, and you forgot to attach it, VI is broken without it.

[altenbach · Accepted solution]

For reference, you should always include a link when referring to found code. You should also read that thread and recognize that there is nothing useful about such a button.

Xcontrols are not very useful in general and hard to do right. If you want to learn, LabVIEW includes some examples, so start there. I recommend not to waste time on xcontrols and study more useful LabVIEW features instead.

[GRCK5000]

Thank you, Andrey and Mr. Altenbach, for the useful information. I will definitely try to find the link to the code, but what you shared is more than enough. Thank you! If there is a better way to run a VI without having to mess with XControl, I would like to know. 

[daveTW]

Hello GRCKFiveThousand,

perhaps we can help better if you describe the task you want to accomplish.

I think, there is nothin wrong with clicking on the arrow button. If you want to make the VI starting automatically when opened, you can do this via the VI properties (Ctrl+i).

[ConnerP]

---

@GRCK5000 wrote:

Thank you, Andrey and Mr. Altenbach, for the useful information. I will definitely try to find the link to the code, but what you shared is more than enough. Thank you! If there is a better way to run a VI without having to mess with XControl, I would like to know. 

---

Preferred option: build your vi into an .exe. It is just a normal program that runs when opened.

More hacky option: set vi to execute when opened.

[Andrey_Dmitriev]

---

@GRCK5000 wrote:

Thank you, Andrey and Mr. Altenbach, for the useful information. I will definitely try to find the link to the code, but what you shared is more than enough. Thank you! If there is a better way to run a VI without having to mess with XControl, I would like to know. 

---

You're welcome! In general I'll fully agree with Christian that XControls are not easy to develop and even harder to debug, but I will not agree that they are completely useless.

For example, control such this one:

Initially was based on trivial arrays with clusters (was done by me in LabVIEW 6.1 in 2001), and it was lot of code to handle, especially for decorations, but once wrapped to XControl, then top-level code was much cleaner. Unfortunately can't share source, because some proprietary parts inside, may be I'll rewrite it someday privately.

But what I can share is this one:

This is table like "DataGrid" with selector, the "native" source was taken from this forum (sorry, don't remember original topic and author) and it looks like this:

When wrapped to XControl it looks like that from top-level VI point of view:

Theoretically it could be possible to do the same without XControl using SubVIs and passing references to it, or may be using SubPanel (impossible is nothing), but I don't think that the code will be so clean as shown above. Source in attachment "DataGrid.zip".

About SubPanels — one more old example, taken from this message Re: Community Nugget: GUI Components using Sub-Panels:

It is a linked list of SubPanels with Dock/Undock functionality and "floating panels". Source in attachment as well in "UI_Panels.zip".

And modification of the code above from this message Re: Subpanel grid? : 

Here SubPanels created dynamically based on Template. Can be also used to "emulate" programmatically created controls in LabVIEW ("out of the box" you can't do it). Source code in "GUI_Example.zip"

If you would like to stay away from XControls, there is another "technology" exists called "QControl". Good starting point is here: QControl Enthusiasts, and also recommended by Darren Nattinger, he wrote: "I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit."

But both XControls and QControls are based on the basic LabVIEW's controls and their combination in some forms with limited customization possibilities. If you would like to stay away from these controls to be able to create "Ultimate customized GUI", then you can wrap C#/WPF control into WinForm container, then using is in LabVIEW, this one from this Solution:

and the top level source as simple as following:

WPF is fantastic technology, where visual appearance, behaviors, bindings, etc are "programmed" in xaml, but this will add huge .net dependencies, this is what I will not recommend (not for beginners anyway), but again, "impossible is nothing"... Source in CircularWPF.7z, (in 7-Zip format, because NI Web page not accept zip for some unknown reason).

Hope this will give you some ideas...

[Yamaeda]

"I had a problem in LabVIEW so i created an XControl. Now i have two problems."

Darren strongly recommends QControls to XControls if you must use such things according to a video i saw last week. X is often a cause of failed builds.

[Andrey_Dmitriev]

---

@Yamaeda wrote:

"I had a problem in LabVIEW so i created an XControl. Now i have two problems."

Darren strongly recommends QControls to XControls if you must use such things according to a video i saw last week. X is often a cause of failed builds.

---

Yes, that is true. When follow "XControl" way, then often builds are essentials to catch the moment when after some modifications you can't build app any longer to step back and looking for workaround. But for me it "stabilized" and works as stand alone executable as well as when loaded dynamically in PlugIns architecture.

On the other hand, I've got some minor troubles with resizing of QControl (but I haven't these in production yet, just played around). In additional, XControls are available "out of the box", but for QControls additional dependencies are required (which is not a very big deal).  Anyway when new control is need I think it make sense to make "a drafts" based on both approaches as "feasibility study", then choose one which better suitable for desired functionality. Each one have pros and cons, I'm very happy that both are "co-exists" at the moment.

[altenbach]

---

@GRCK5000 wrote:

 Thank you! If there is a better way to run a VI without having to mess with XControl, I would like to know. 

---

The absolute best way to run a VI during development is the run button in the toolbar. Nothing can beat the simplicity of that!

Once the application is complete and built as standalone executable, edit mode (i.e. NOT running) is no longer a useful state and the end user should never be confronted with it. The toplevel program needs to be a state machine that runs when opened, typically in an idle state waiting for the user to initiate an action. Once the user is done, it should close and not return to "not running". The toolbar should never be visible.

To have both, I typically have a "window close?" filtering even that I discard, then initiate the needed shutdown procedures. After that I use a conditional disable structure to return to edit mode if running in the development system, but close if running in the runtime engine. This way the program can be ended with the "X" in the upper right corner, not with a weird stop button. Every user in the world knows how to close a window wit the "X". A stop button on the front panel is highly unusual and no other program has that. In development, it will just return to edit mode, which is especially important if there are still unsaved changed or new modifications need to be made.

For detail look at my old presentation ( slides 27+ here or watch the video starting at time ~18:30).