User | Kudos |
---|---|
10 | |
6 | |
6 | |
5 | |
4 |
As application developers, one of our tasks is to create intuitive and easy to use User Interfaces. One facet of that intuitiveness is guiding users of our applications as they use it. LabVIEW has done a great job in helping us in one way in particular: data validation on entry. You can configure "Data Entry" on various controls. For example, on a numeric you can set the Minimum \ Maximum allowable values that a user can type into a control and then how to respond if they exceed those limits.
However... I often find myself wanting to do something beyond what's on the "Data Entry" tab. So I immediately jump to a subvi and pass the control's contents through my custom validation routine. And that's fine and dandy, but what if that control appears in multiple places throughout my application? Well, the vi has to follow every instance of the control, or the architecture has to redirect the entered data to the single vi.
I feel like LabVIEW did a great job with the first swing at integrating data validation into a control, but I'd like to be able to customize that validation as a PART of the control.
Now before you get all excited about XControls, I agree that an XControl would solve this problem. But to be honest, the development of an XControl is pretty expensive when really all I want to do is something like "the valid range of inputs for this control are 0-100 and 200-212" or "only powers of 2" or "my DAQ card has a 20Mhz clock and only certain sample rates can be specified". So here's what I propose: a block diagram associated with a type def that will execute on value change. The purpose of that block diagram is ONLY data validation, NOT UI manipulation (on fail, turn the control red etc.).
Here's my proposed work flow. Go through the normal steps to create a type def by right clicking a control and selecting "customize". But now I would like to see a 4th option in the ring control. "Custom Validation". When custom validation is selected, a block diagram would appear that is now tied to the front panel and the extension remains .ctl.
There would be a control and indicator of the type def on the block diagram and you put your custom code between them. On fail of validation you can set the ouptut to what you feel is appropriate.
So that would be cool... Now let's get to feature creep 🙂
I could see a use case where on data validation fail, return an error. But an error from what? I'd like to see error terminals on controls and indicators. Passing an error in and out could allow me to build in some additional logic directly into the control instead of being forced to make it application specific.
Really the main thrust of this idea is that I'd like to see the algorithms acting on controls be more directly integrated into those controls. I don't think this paradigm should be used in all circumstances. Sometimes the algorithms do need to be separate. But I'd like the option to embed data validation into a control without having to put together an XControl. To help support my point of the overhead of getting an XControl up and running, please feel free to reference the NI white paper on Creating New Front Panel Objects with LabVIEW XControls. I think you'll quickly agree that an XControl in this case is overkill.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.