Improved data entry specifications

[X.]

I just got bitten by a classic: a parameter was set to  big no-no value (zero) and I went ahead making a division by this number, creating an array of the resulting size, throwing a "Not enough memory for this operation" error, stopping LV.

I could have tested for a zero value, but most of the time, this kind of problems would be more easily prevented by a more powerful "Data Entry" Properties Tab.

Currently, taking the zero value as an example, you can set the value zero as the Minimum value, but cannot IGNORE it, because the ignore condition is interpreted as a strict inequality:

ignore all x such that x < min.

What I need is:

ignore all x such that x <= min.

In other words, when I overwrote the previous value of 0.1 by what I though was 0.01 but in fact was 0, my control would have ignoredthe new value and remained 0.1, preventing the annoying out of memory error and VI stopping.

To solve this kind of problem, my suggestion is to have the equivalent of the "In Range and Coerce" options in the "Data Entry" tab:

 <================

in other words, the ability to include or exclude the min and max value from the accepted values.

If I may, it might be useful to have an arry of such conditions, but I will not push my hopes to far on this one...

PS: Obviously, this could be result in ambiguities with Floating point values different from zero, due to the finite precision of their representation. And it would be compounded due to the current bug in the Data Entry tab regarding the displayed precision of numeric values in this tab.

[tst]

I'm not sure I understood you, but I think you misunderstood the meaning of "ignore". It doesn't mean "ignore this value and all below it". It means "ignore the fact that the value the user entered deviates from this minimum and accept their value anyway". If you want it to coerce you simply need to change the ring to "coerce".

In your specific case, I would say you simply should have set the minimum to 0.01 or 0.1 and to coerce and be done with it. That's what I usually do when I don't want the user to enter 0.

I would say that there is a case for making these values default to coerce rather than to ignore, because if the user decided not to use the default limits, they probably also want the control to coerce.

Side note - all these settings only affect the UI. You can still enter whichever value you want using a local variable (and yes, this is explicitly by design. It was actually changed to do this, so I wouldn't expect NI would change it back).

[X.]

1) I think I did indeed overlook the fact that "ignore" (for the Minimum) does IGNORE user action ONLY when user action is a press on the increment/decrement button (as explained in the Help):

Ignore: LabVIEW does not change or flag invalid values. Clicking the increment and decrement buttons changes the value by the increment you set, but the value does not go beyond the minimum or maximum values.

It does indeed NOT ignore user entered value that are out of range. In other words, if the user TYPED -1 in the example above, it would be accepted.

So there you go:

Additional suggestion: please do not redefine the meaning of words. That is DO IGNORE all values entered by the user, be it using the increment/decrement buttons (*) or by direct typing, or value passing on the diagram (local variable, property node, etc).

(*) I now hide those buttons pretty much systematically in my UIs as they are not useful at all.

2) This being said, I don't think the "solution" that you propose, namely set a defaut increment, is practical in all cases. Certainly not in mine. I don't want to prevent the user to enter any arbitrary small value (although I probably would run into memory allocation issues in some cases and should definitely check for that in the future). I only want to prevent them to enter ZERO. The strict condition is needed for that, so I stand by my original suggestion.

3) It is a shame that the intended bahavior has been changed. I can't believe that I am the only one to expect this can of UI behavior. I certainly could put some code to check, overwrite and pop-up messages, but I am just wondering what the use of the Data Entry properties is then...

[RavensFan]

I think you are confused.

Ignore doesn't mean ignore the user, it means ignore the coercion.

I don't know why you think the behavior has been changed.  My recollection is that it has always behaved as it is.

[X.]

I guess I am confused because it is called "Ignore" rather than "Ignore the Coercion", or maybe because it is an option of "response to value outside limits", so based on elementary logic and basic English syntax understanding... oh well, some day I will have to admit that LabVIEW is really reserved for an elite few.

As far as the change I was talking about, I was just following up on tst's explanation. I had no idea that there had been any change in behavior.

[tst]

---

This being said, I don't think the "solution" that you propose, namely set a defaut increment, is practical in all cases. Certainly not in mine. I don't want to prevent the user to enter any arbitrary small value (although I probably would run into memory allocation issues in some cases and should definitely check for that in the future). I only want to prevent them to enter ZERO.

---

I didn't suggest setting the increment. I suggested setting the minimum. And incidentally, you DO want to prevent the user from entering an arbitrarly small value. At the extreme, you're talking about setting the minimum as 0 + the machine epsilon for the data type, but since that is probably meaningless, and it would probably just be confusing to have to start defining things like > or >=, it's easier if you just set the minimum yourself to 0.0000001 and be done with it.

As for the history, in older versions (I think it was pre-7.0) the settings you configured in this dialog also applied to locals and value properties (and I think inputs on subVIs and the Set Ctl Val method). NI decided to remove it on all programmatic interaction, presumably both to give the programmer more freedom and to make the code more explicit (i.e. if you want to coerce, write explicit coercion code).

And I feel a little proud that I managed to restrain myself and not preface this reply with the "ignoring (ha ha) the discussion about confusing lanaguge" text I wanted to add (although adding it here reduces that sense of pride).

[X.]

Considering that the Property Tab is named DATA ENTRY (not data passing), I feel justified in assuming that its whole business is about handling what a user does to a control. And IGNORING a typed value makes sense in this context, since the UI can revert to the previous (acceptable) value.

As it is functioning now, I'd argue that the behavior is useless since a user CAN input a value that is out of range by TYPING it. I am glad to hear that programmers at NI can sleep with this aberation for everyone to witness, but out of magnanimity, in addition to my suggestions above, I'll add this one:

Additional Suggestion: Make the IGNORE option behave as EXPECTED, i.e. IGNORE an out of range value TYPED by the user.

Ignoring a "passed" value (or set value using a property node) does indeed raise some issues (e.g. what value to revert to?) and therefore I can understand that this functionality has been dropped (I now vaguely remember this debate way back then).

The fact that you restrained yourself (well, not quite) makes me hopeful that maybe the sense of humor might not be totally lost for everyone on that forum.

[tst]

What you're asking for is a completely new feature. Today, the only two options are "always accept the typed input" or "coerce to the limit". You seem to want a new option which would be "revert if outside the limit". Correct?

Also, it seems like you also want the language to change, but to what? "Ignore" doesn't make much sense to me the way you describe it. The options I gave above are (I think) clearer, but I'm fine with the current language. If these are what you want, I would suggest you create a new idea which makes that clear.

Like I said earlier, what I would change sooner about that dialog is the default value of the selectors - it makes some sense that if you enabled the check box, you want the limits to coerce by default. I'll probably write it up as a separate idea when I can create a screenshot.

And as for the usefulness of the behavior, I don't really have a comment on that. I tend to agree that a limit should either be enforced or not exist, but I'm assuming that this was implemented that way to allow for a case where you want the enc/dec buttons to be limited, but still allow the user to type in a free value. I'm not sure where such a case would be relevant, but that doesn't mean it doesn't exist.

[X.]

Agreed.

With zero traction on this discussion, I don't think I am going to bother creating a new post about UI design and Numeric Data Entry...

[tst]

I'm not sure what you mean by "zero traction". You did get zero votes, but I think that's because your idea is unclear. You certainly did get a discussion. If you post another idea which is clearer you might (or might not) get the votes. It's up to you as to whether it's worth the bother of creating another idea.

[X.]

I think you convinced me.

My final suggestion for Data Entry is therefore:

Suppress the Data Entry Properties Tab, as we have to resort to an Event Structure "Value Change" anyway in order to have something that actually makes practical sense.