Dialogue box critique

Question

Hi all,
I've been trying (in vain) to create a good dialogue box that does some bounds checking on user inputs before allowing them to be sent to the main application. Ideally, when an input is out of range, it'll blink until it gets put into range. Generally this means that bounds can only be positive (nonzero, nonnegative numbers) and that VISA resources cannot be left blank. Additionally, the difference between two of them must be bigger than or equal to 40(Range Max - Range Min >= 40). Normally, my code is pretty modular, but I think this being my first real foray into UI design has left me struggling to make things look and work nicely. I've posted the VIs thus far for critique.
I've described how it should work. As to how it's actually working, I've noticed that whenever I have two things that are out of range, and I fix one, the OK button is no longer blocked. I think this may have to do with how my events are set up, but can't be sure. What do you think? How can I make this better? Am I missing something fundamental in my design layout?
thanks,
ijustlovemath
Attachments:
constant control_test.ctl ‏8 KB
constants_dialog.vi ‏55 KB

Answer 1

ijustlovemath wrote:
Range Min and Range Max need to be set exactly by the user, so while I do like the idea behind the slider, I think it would just end up cluttering the dialogue while not adding much. Could you explain the "Abort VI" suggestion a little more? Also, what do you mean by using shift registers? Would that be used for just reading new values, or what?
So you make them "Coerced" as well, force them to be done first (by making only Min visible, using Min's value to set the Min for Max, making Max visible, then using Max and Min's value to set the other Range Control and make it Visible).  Once you have the range set, make Min and Max invisible.  By doing this, you gently lead the user by the nose through the correct steps.
Here is a Snippet of (some of) the rest of your question.  This picture can be "dragged" onto a blank Block Diagram and it will magically become LabVIEW code.
Here are points to note:
Following Standard NI Practice, Error In and Error Out are present.
The Invoke node to reset Constants to its default value comes next.
The (now default) Constant is brought into the While/Event loop on a shift register.
In a frame that you don't see, the Weight-changed Event is used in a Bundle-by-Name to change the Weight on the wire in the Shift Register, thereby storing the new value.
This shows what happens when Cancel is pushed.  First, we generate Error 5001, with the Error Message "User Cancelled!".  Then we exit the While loop by setting the Stop Indicator to True.  It is the User's responsibility to check if there is an Error present on the Error Line (wire the Error line to a Case Statement selector) and take appropriate action (but, please, not Abort VI).
The OK case is identical to this except there is no Error Cluster.
Bob Schor