App Designer editfield format not respected during entry

When I create EditFields to display numbers in the (custom) format '%.1e', i.e. 10^-6 it is rendered as "1.0e-06" and 10^-10 as "1.0e-10".

However, the behavior is very strange: As soon as one clicks into an EditField to change the value, the display format changes... "1.0e-06" all of a sudden switches to "0.000001", and "1.0e-10" to "1e-10" (i.e. it swallows the decimal). Once the new values are entered, they are again displayed in the correct format, but the back-and-forth switching during entry is very confusing for the user.

How can I maintain consistent formatting whether the EditField is clicked or not?

Answer 1

[MathWorks Support Team]

Attached is an MLAPP-file which demonstrates the desired behavior in EditField3, compared to EditField1 and EditField2.

EditField3 achieves this behavior by making the EditField text instead of numeric, and then giving it a ValueChanged callback function which checks for the new input and adapts the format accordingly. It also goes back to its previous value if a non-numeric value is entered.

Please note this file was created as a simple demonstration for how this might be done and may not account for all edge cases.

[Chris Portal]

To help explain the behavior of the numeric edit field, the ValueDisplayFormat only controls the displayed value, not the actual value being edited as you noted. We considered offering control for both, but it can lead users to introduce undesired behaviors into their apps. For example, if you format the following as %.1e you would get:

 sprintf('%0.1e',1.00000001)

 ans =

    '1.0e+00'

Displaying the formatted version is safe, but if we also display it when editing the value, the user of the app would unknowingly lose the precision they had entered. This loss of data is something the component is trying to help prevent.

Just a scenario to be aware of.

[Chris Portal]

Forgot to mention, the inconsistent presentation when editing in the 2 cases mentioned looks funny to me too. I’ve logged that as a bug so it can be looked into. Thanks!