A more successful experiment in creating compositable user interfaces for Config Dialogs

Question

A couple weeks ago I posted an experiment in creating compositable user interfaces using transparent subpanels. The approach might best be described as, "It at least was notable for being novel."
Today, I'm posting another attempt, this one along more traditional lines, and far more successful. Particularly notable: this one can do all the arbitrary composition of the last one AND it solves the TAB order problem.
This solution uses a picture control and renders N copies of a control. When the user tabs to a control or moves the mouse over the control, a real control slides into that position to be able to catch the events (update mouse over draw state, highlight for keyboard focus, handle typing, etc). When the Value Change occurs, a master array of data is updated and the picture control is updated.
This is something that has been attempted in various forms in the past, but there are two aspects of this particular implementation that make it nice:
its programmatic interface for specifying the behavior of the various objects should make it fairly easy for a user of the framework to programmatically generate their dialogs
it handles the TAB problem without flickering, something I haven't seen in other attemps
This idea spawns out of conversation about the previous experiment -- thanks to those of you who posted on various forums, e-mailed me, or, in a couple cases, showed up at my desk. That last one is not something I'm encouraging unless you work at NI... just saying. :-)
Now, this experiement has already yeilded some interesting conversation. We note that as long as controls are instantiated independent of each other -- that is, no property of one control depends upon the property of another control -- this dialog system scales nicely. But in this experiment, I implemented Radio Buttons, which interact with each other -- when one is set True, the others go False. As soon as controls start interacting with each other (such as graying out one control when a checkbox is toggled, or having expandable sections, or really complex cases like updating a graph as some options change, like happens in some Express VI config dialogs) then we start needing ways to refer to the other controls. This rapidly moves us in one of two directions: naming controls or creating references. The naming approach is definitely my preference as it fits better with dataflow and I can do some interesting effects with breaking apart some of the tree. But all of this quickly starts sounding like "Please implement a XAML parser in LabVIEW." For those of you unfamiliar with XAML, in the world of UI design, it might very well be the coolest thing since sliced bread. A XAML string would indeed fit with dataflow, and we could start building that up. I hesitate to head down this road for two reasons. One, as many have noted, there's really not a good XML parsing library written in LabVIEW that can give me a useful DOM tree. Two, that's a huge project and my gut sense is that you'd have to complete a fairly large chunk of it before you'd start seeing any return on investment. But it is worth thinking about -- I might be wrong. Wouldn't be the first time. This code that I've posted today can at least get you started on the generation side if one of you decides to become industrious.
I'm turning my attention away from this project for now... coding in G is lots of fun, and I wish I could spend more days doing it, but this has been a side project and it's time to get back to my assigned projects in text programming. Building a powerful platform for automatic UI generation in LabVIEW would be really useful -- I see lots of requests for this sort of thing, and other languages are pulling ahead of us in this domain.
[UPDATE 5/17/2012 - There is an improved version.]
Solved!
Go to Solution.
Attachments:
ConfighThroughCtrlCreation.zip ‏558 KB

Answer 1

Elijah K wrote:
Thanks for posting this Aristos.  I would normally be one of those to go bug you at your desk, but in case I'm not the only one with this question... which particular flickering problem are you referring to?  The act of switching tabs?  In all honesty, I've never noticed...
When you move controls around on the screen, normally you try to Defer Panel Updates while you do that. But Defer Panel Updates has an effect on control's abilities to catch certain mouse clicks, so when you're trying to move a control to catch the mouse, you have to work a lot without Defer Panel Updates, so if you're adjusting captions, etc, to match the new location, you can see flicker as properties adjust. You can move the control off-screen, as long as you have already updated the picture control to reflect the changes. It took a while to catch all the ways that the flickering can crop up. I think I got 'em all.
Attached are the VIs saved for LV 2009. Actually, they're saved for LV 8.6, but it doesn't work in 8.6 because of a bug in the picture control that existed back then.
Attachments:
ComposableUI_LV2009.zip ‏391 KB