An experiment in creating compositab​le user interfaces for Config Dialogs

Question

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...
Solved!
Go to Solution.
Attachments:
SubpanelEvents3.zip ‏284 KB

Answer 1

Just throwing out three ideas that could also come in handy here:
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
Programmatic access to control's z-order as a property (has an Idea been created for this? I would vote for it)
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.
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}