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 controls behind it 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...

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.

LabVIEW

An experiment in creating compositable user interfaces for Config Dialogs

Solved!

For future reference, I just noticed something in my example - in the listbox option, the cfg dlg VI in the dog class hasn't been modified correctly. Look at the one in the animal class to see how it works with listbox (a single call to the DVR).

___________________
Try to take over the world!

Message 11 of 11

(819 Views)

LabVIEW

An experiment in creating compositable user interfaces for Config Dialogs

Re: An experiment in creating compositable user interfaces for Config Dialogs