Intended behavior or bug? Numeric Text Field Decimal Format affects underlying value

Not sure if this is a bug or the intended behavior, but regardless, I think the behavior of the numeric text field needs to be re-evaluated.

Problem

By default, the decimal format is #,##0.##. Even though this this property exists under the “appearance” category in the property browser, it fundamentally changes the underlying values that are allowed to be stored through the numeric text field.

To illustrate why I think there is an issue, I will compare the behavior of the tag value field in the tag browser with the behavior of the numeric text field.

Tested on 8.0.15

Tag Browser

Steps:

  1. A tag has the default number format of #,##0.##.
  2. The value is 0.0006
  3. When browsing the tag tree, the value field shows 0, which is the rounded display text.
  4. When you click on the field to edit the value, the field is populated by the true 0.0006 value to be edited.
  5. When you enter 0.0007, the value is accepted, but still displayed as 0.

So, even though the default format rounds the display text to 0, it still continues to function and store the correct value in the tag.

Numeric Text Field

Steps:

  1. The field has the default number format of #,##0.##.
  2. The float value is bound to the above tag which is storing 0.0006
  3. When you open a window with this field, it shows 0, which is the rounded display text.
  4. When you click on the field to edit the value, the field still still shows “0” and not the real value of the underlying tag.
  5. When you enter 0.0007, the value is rounded to 0.0 and THEN written to the tag. The tag receives a value of 0, which the user never entered.

In this instance, the numeric text field writes an unintended value to the underlying tag… When you build screens with it, you need to make sure that the number format of every field is changed to something like #,##0.######### to make sure you can accept entries of whatever the user desires to enter. This doesn’t seem like it should be the default behavior.

Possible fixes

Options:

  1. Make the field behave like the tag value field in the tag browser example.

  2. Add a separate, valueFormat property to the data category of properties in addition to the decimalFormat property listed under the appearance category. The new valueFormat property controls what the underlying stored data will look like and decimalFormat only controls how that value is displayed.

Additional Bug

While looking into this, I discovered that you can drag a client tag onto the numeric text field and it will bind [client]Test.FormatString to the decimalFormat property. This also occurs for other properties like engineering min and max. The problem is that client tags don’t have these properties.

If you made it this far, thanks for the read. I never thought I could write so much about the numeric text field.

1 Like

Today, I noticed that the perspective version of the numeric entry field behaves correctly. It displays the true value when focus is gained.