Building dynamic UIs with subVIs and sub panels

[Bob_Schor]

At NIWeek 2019, I described a Project where I had up to 24 "Stations" which contained a Balance and a Video Camera as part of an animal behavior study.  Each Station was a "Clone" (pre-allocated reentrant sub-VI) that was running asynchronously (using Start Asynchronous Call).  I had a single sub-Panel and could select which Station I wished to display in the sub-Panel -- when the Station-to-be-displayed Control changed in the Top-Level VI, I merely removed the existing Station Reference from the sub-Panel and put in the new Reference.  Worked like a charm.

Bob Schor

[BertMcMahan]

---

@Bob_Schor wrote:

At NIWeek 2019, I described a Project where I had up to 24 "Stations" which contained a Balance and a Video Camera as part of an animal behavior study.  Each Station was a "Clone" (pre-allocated reentrant sub-VI) that was running asynchronously (using Start Asynchronous Call).  I had a single sub-Panel and could select which Station I wished to display in the sub-Panel -- when the Station-to-be-displayed Control changed in the Top-Level VI, I merely removed the existing Station Reference from the sub-Panel and put in the new Reference.  Worked like a charm.

Bob Schor

---

Assuming that was a presentation, any chance it made it online somewhere? I'd love to see it. I know I could handle something like that regarding subpanels, but I still haven't found a great way to handle stored configurations for expandable test systems like that. I've made it work but I always feel like there's a better way. That, and doing data compilation outside of the reentrant subsystems (like, for example, having a view combining all of the stations showing all of the balances in one chart or something). Just getting the data moved around asynchronous "actors" (whether or not AF) without heavily coupling the system is definitely a growth area for me.

[JKSH]

---

@wgeithner wrote:

I will stay hard coded LabVIEW core for the moment as I am not sure what the implications will be if I use the lib you propose (maintenance, long term strategy, etc.)

---

That makes sense.

Other users have posted links to various native LabVIEW solutions; do try them out. All the best with your project.

[wiebe@CARYA]

What is wrong with a number (enough to fit your needs) of subpanels and populate them?

You'd need to manage them. But then, if it was possible to put multiple VIs in one subpanel, you'd need to manage them as well. They'd not magically appear exactly as you want.

[wgeithner]

Well, I am a Java/Python/C# programmer with some experience there. In these languages it is no problem to build classes defining sets of UI components and to instanciate these components dynamically from database data. Normally, I am used to build UIs with nothing hard coded but the main frame and maybe two-three layouting elements. This is functionality I would like to re-produce in LabView.

The background of my question is that I want to build about 5 to 10 VIs, with same control types (maybe 4 types), but different number of controls controls and layouts, representing subsystems of a larger machine. Instead of repeating my code, it would be better to have one UI generator, which generates all UIs dynamically from database entries.

Having hard-coded sub-VIs is kind of OK, but not very satisfying from an architecture perspective and if the machine evaolved, I have to touch the code instead of simply changing configuration data on DB.

[wiebe@CARYA]

I do understand the benefit of a dynamically generated UI.

But why not make it with enough sub panels that are populated and organized by the program?

Anyway, that is the closes you will get to dynamically generated UI.

There are variations on the theme, like making a VI with a subpanel that can recursively be put in a subpanel (giving infinite number of subpanels).

This is, btw.,  something that we would all welcome. LV NXG had it, so it's probably on NI's radar. Somewhere...