XControl hierarchy for event handling

[DaveKielpinski]

Dear all,

I've been thinking about how to cleanly write user interfaces for large applications. One major problem for me was identifying a nice abstraction hierarchy for event handling. Possibly this could be handled in LVOOP, but my attempts on that path have not been very successful. Recently I found a way using XControls and I'd appreciate the opinions of advanced users, especially those using LVOOP.

As far as I can tell, an LV control is really a simple event handler with data in it. The events are just hidden - for instance, when you change the control value on the FP, the data corresponding to the control is updated in the BD. That looks a lot like what happens during the "Data Change" event of an XControl. So let's turn it around and take _XControls as the primitive data-carriers for LV, rather than regular controls. From this point of view, a regular control is a _restricted_ type of XControl because it only accepts certain NI-defined events.

Now consider a tree structure where the nodes are XControls and the links are provided by a messaging system. Each node's Facade contains an instance of each descendent XControl one level down in the tree. For each possible event in the UI, we create an event handling case in the lowest-level node that is competent to the task. If an event in one node indirectly affects other nodes, it is sent up to the nearest common ancestor by the messaging system. The ancestor instructs the descendant nodes by altering the State of each node through custom properties, so the Display State Change case of each XControl takes care of downward messaging. It's easy to set up a second by-value tree that uses the Data of each XControl as a node and a Data Change event in the ancestor Facade as a link, so you can make a complex data type that is built up dynamically by UI events.

There are some nice encapsulation properties to this way of building a UI event handler and it seems like it could be widely applied. I've verified that the upward messaging can be done conveniently with User Events containing queues of strict typedef'd Enum commands. If anyone is interested I will be happy to post code snippets to show what I mean. It might be really nice to have an LV class for the XControls that make up the nodes, but that is beyond my abilities right now.

Best,

Dave

[Ton Plomp]

Give me some time to absorb, it's 6 in the morning.

Ton

PS It looks nice though

[DaveKielpinski]

Well, this seems to have gone over like a lead balloon I guess it's either

1) tl;dr

2) a lousy idea

Please don't be shy if it's #2, I would really like feedback.

[JDave]

QUOTE(DaveKielpinski @ Dec 25 2007, 09:58 PM)

Well, this seems to have gone over like a lead balloon I guess it's either

1) tl;dr

2) a lousy idea

Please don't be shy if it's #2, I would really like feedback.

or

3) Did read; Over my head

4) On vacation

[Richard_Jennings]

QUOTE(DaveKielpinski @ Dec 25 2007, 08:58 PM)

Well, this seems to have gone over like a lead balloon I guess it's either

1) tl;dr

2) a lousy idea

Please don't be shy if it's #2, I would really like feedback.

Hi Dave,

#2 - unless you are trying to make your application impossible for anyone else to debug Dataflow and the ease of debugging a LabVIEW app by another programmer would be thrown out the window.

XControls provide a great way to enhance a UI without unnecessarily complicating the block diagram, but hiding an elaborate messaging scheme would - I think - be the wrong way to use them.

Richard

[DaveKielpinski]

QUOTE(Richard_Jennings @ Dec 27 2007, 12:50 PM)

#2 - unless you are trying to make your application impossible for anyone else to debug Dataflow and the ease of debugging a LabVIEW app by another programmer would be thrown out the window.

XControls provide a great way to enhance a UI without unnecessarily complicating the block diagram, but hiding an elaborate messaging scheme would - I think - be the wrong way to use them.

Hmm. I may have made this sound more complicated than it is. A message gets passed out from the XControl when a relevant event is triggered (SubcontrolEvent.png). The registered User Event in the shell then fires (ShellEvent.png) and any queued messages are dequeued and handled. I suppose I didn't HAVE to use a queue, but it's more robust. Is there a simpler way to pass messages between VI's?

I am only suggesting this technique for relatively large applications (several hundred subVIs) like the one I am working on. In this case there is already a significant problem with debugging by other programmers, which is usually solved by encapsulation. I admit I have only programmed relatively simple UI's in the past, but I haven't found another way to encapsulate event handling in a self-similar hierarchy. Do you know another way to do this?

Also, is dataflow really thrown out? Each subcontrol passes its data up to its parent, which collates the data from all its subcontrols and passes up the relevant data to the next level up the tree. The root of the tree looks like a simple control that passes out the relevant data collected from the descendents. The data from the root is dynamically altered by events in the subcontrols, so it's not necessary to recompute the entire root data every time there is a minor change. If the root data is large or complex, this could save on computing resources.