An experiment in creating compositable user interfaces for Config Dialogs

[AristosQueue (NI)]

The attached files are saved in LV 2009. They are an experiment. Please don't go off and say, "NI says this is how you should make an options dialog."

Oh -- I guess I should mention -- this is an experiment in how to make an options dialog that can be reused, extended, and modified for hierarchial systems. In other words, I can create a UI of options for all DAQ cards, then reuse that dialog and append options specifically for M series cards, then reuse that dialog and append options for a specific card. At each level, I can choose to reuse the entire existing set of options, I can reduce or disable certain options, and I can add new options, and when I hit the OK button, out pops a single configuration object for the chosen card.

That's the goal.

This experiment achieves some portion of that. I did a lot of work with subpanels with a transparent background.

I hate the TAB key. I've got no solution to the problem of how to set up the tabbing properly through the controls of these various subpanels. Annoying. And this project did lead me to file an Idea Exchange entry for transparent subpanels: Subpanels with "Make Panel Transparent" enabled should allow mouse clicks to fall through to control...

To take a look at this experiment, unzip the attachment, open the project file, and open Caller.vi. There are detailed instructions and explanations of what you're seeing on the front panel of that VI. I've put comments in various places throughout. The code is ok quality -- it won't win any awards for following style guidelines, but most of the wires run straight. The whole thing is just to see how far I could go with this approach to compositing interfaces.

Oh, and if you learn anything from any of this, send a thank you note to user tst. He had an initial framework he was working with, which happened to hit on a day when I was able to spend some time looking into it, and his code inspired me to try this other approach. At the end of it, I don't know how useful this approach will ever be for actual production code, but it is a technique I've never seen anywhere before... perhaps someone out there will be as inspired by my experiment as I was by tst's and will find a way to make this better. Because, honestly, creating an extensible UI framework is a HARD problem, and LV has several approaches that kind of work, but none are particularly great. It would be nice to have a cannonical "this is the way NI and the CLAs say we should write an options dialog".

And now, having spent some time on "R", I need to get back to the "D" part of R&D...

[tst · Accepted solution]

I'm attaching the original example I sent to AQ. It shows two alternate ways of arranging the GUI - one using a listbox and one using vertically-stacked subpanels. I think both are simpler than his approach.

Note that we use very different approaches in how the dialogs references are acquired. You should note that both examples are proofs of concept and have various issues.

Anyway, if you want to see where this discussion started and where my example was initially posted, look here, where there's also a short video and an image.

[JackDunaway]

Just throwing out three ideas that could also come in handy here:

1. A "Mouse Simulator" API that can simulate mouse clicks/hovers/drags/drops on an object. For this particular application (composite UI), the top-most panel could broker clicks to lower-z-order panels
2. Programmatic access to control's z-order as a property (has an Idea been created for this? I would vote for it)
3. Make the "Inserted VI" the 'Value' of the SubPanel rather than a 'Property' so you can have an array of SubPanels that contain different UIs. Although I didn't articulate this well, that's why I got excited here.

[AristosQueue (NI)]

> Programmatic access to control's z-order as a property (has an Idea been created for this? I would vote for it)

Go ahead and add it.

[AristosQueue (NI)]

Oh, I also found that I could've used a "Reset VI's Panel To The Way It Is Saved On Disk" method. That means putting all properties back, moving positions, making visible controls visible and hiding invisible ones, etc. as well as sizing and scrolling the panel to its saved origin. There's "Revert VI", but I don't think that works in a built application, which I obviously want this to work in.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-quot-Reset-VI-s-Panel-To-The-Way-It-Is-Saved-On...

[JackDunaway]

---

@Aristos Queue wrote:

> Programmatic access to control's z-order as a property (has an Idea been created for this? I would vote for it)

Go ahead and add it.

---

Done.

[tinnitus]

Hello,

I had feeling that xcontrol could help in creating compositable ui ( associated to lv class).

May be i 'm wrong and seen that from far away.

 I would like to make tries on it

Unfortunatly i don't have xcontrol tool on LV i use ( not been informed of all differences full/pro).

Did anyone try ?

Best regards

Tinnitus

[AristosQueue (NI)]

XControl is a way of packaging some UI code so that it drops as a single control. You still have to write the UI code that makes up the XControl. My post and the two posted by tst are all ways that you would write the core code of the XControl. So, if we ever figure out how to write compositable UIs in a way that satisfies everyone, we would likely wrap the results in an XControl, but "Use an XControl" does not by itself explain how to write the code for this particular XControl.

[AristosQueue (NI)]

PS: If you are trying to create a UI for a particular LV class, yes, XControls are the answer. The work posted here is trying to solve a much broader problem -- an XControl that does not have intimate knowledge of all possible classes that it is going to display, merely a framework that the class would fill in.

[AristosQueue (NI)]

I've posted another experiment on this same topic here.