Complete Min / Max handling for numeric controls ...

[manu.NET]

The numeric controls can be configured by specifying Min/max values ... and behaviour when going over these limits (Coerce, ignore ... )

This feature works fine on the front panels ...

But when you modify the value of such controls programaticaly using a property node ... these constraints are not taken in account.

It would be nice to apply the MIN/Max limits also to the "value property" (and valus signaling too)

 

[manu.NET]

Sorry ... my visual example is bugged ...

Here is the correct version with min value > max value.

Message Edité par manuLerch le 03-05-2010 09:33 AM

[tst]

This feature existed in earlier LabVIEW versions and was changed around the 6.1/7.0 timeframe.

Since this change was by design, I doubt you will get NI to reverse the decision. You can implement this yourself by using the In Range & Coerce primitive.

[silmaril]

I think there should be a property to decide if coercion should work only for user inputs or also for programmatical changes.

This way we could stay compatible with the current behaviour and still make development of new applications easier.

@tst: of course you can do this programmatically. I just don't like the idea of implementing something that already works fine.

Also, control input coercion contains more than the range check you can do with a simple In Range & Coerce. Just try to implement LV's increment coercion algorithm with all it's options (ignore, coerce to nearest/up/down) in your own code. This will cerntainly take you quite a while.

[manu.NET]

I agree with you silmaril .

On all numeric controls should be added a property like "Constraint handling" which could be an enum with the values ...

-> Constraints checked on front panel only (default value)

-> Constraints not checked

-> Constraints checked programmatically only

-> Constraints checked on front panel & programmaticaly

Thanks.

[Dennis_Knutson]

There were very good reasons that this functionality was removed and I would be strongly opposed to it's return. When you have range checking on for front panel, it's obvious to the user that he/she cannot enter values outside the range since the control will not allow that. When a subVI had range checking enforced, there was no feedback when you called the VI. This would cause all sorts of debug issues. A lot of old instrument drivers had this instead of programatic range checks and passing of error messages.

If you are writing the VI in the first place, you should be aware of what ranges you have imposed on the front panel entry, shouldn't you?

[tst]

> Just try to implement LV's increment coercion algorithm with all it's options (ignore, coerce to nearest/up/down) in your own code. This will cerntainly take you quite a while.

I'm not sure why you think it will be complicated. Rounding to a multiple is very simple, and all those options are based on that.

In case you care, to round Y to the nearest multiple of X, the logic is X * Round(Y/X)

[Darren]

Any idea that has received less than 8 kudos within 8 years after posting will be automatically declined.