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

[AristosQueue (NI)]

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:

1. 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
2. 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.]

[AristosQueue (NI) · Accepted solution]

This is not a question. It does not need an answer.

[AristosQueue (NI)]

By the way, to view the experiment, open the .zip file, open the project therein, and then run "Demo Config.vi"

[F._Schubert]

Sorry to say that, but I miss the uml design document.

Felix

[tinnitus]

Hello,

Could you save it as LV 9 please

Regards

Tinnitus

[Elijah_K]

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...

[AristosQueue (NI)]

---

@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.

[AristosQueue (NI)]

I had some more time to work on this. All the VIs are saved for LV 2009, but have only been tested in LV 2010, 2011 and 2012 (yes, this was one of my free-form testing projects).

New version supports Ring controls. Also the API is much improved (IMHO) to make it easier to drop into other projects. And I cleaned up the spacing on the wires and added comments to the diagram, which should make the whole project a lot more readable.

[AristosQueue (NI)]

A small bug fix for numeric text boxes.

[GoofyWires]

Nice. I tackled the issue differently by wraping each UI inside a class, loading FPs into my MVC, searching all the controls and adding via scripting all the relevant messages.

However, in your case, in order to make it a bit more useful, I would change two things:

1. the way you enter each type of control is different. I think it should be the same with all the possible parameters and that a parser should analyze it later.

This way you can create each control programatically without adding the a special structure manually in your demo vi and you could actually have one class that interfaces all the input of controls.

2. If it is possible to add controls to a class cluster I would create a class that reflects the UI state instead of the array of classes, however, I don't think this can be done in run time sadly.

In my way I guarantee that I can load in run time any FP that has the controls names that my logic supported during edit time.

In your way you guarantee that you can create dynamically any basic looking FP that contains the basic controls that your framework supports.

Thus, I think, my way is better for skins while your way is better for forms.

Edit: oh, I think I missed 2 🙂