BigDecimalField handle currency formatted text replacement

[jptinsman]

Issue: When tabbing through a form and into a BigDecimalField, the user would normally just type in the desired number for the field. If the BigDecimalField has a currency format (i.e. $100.00), when the user types in a number (i.e. 150), it fails format validation and does not take the new number.

Solution: I have updated the BigDecimalField to check if the input matches the format. If it does, then it will use the format. If the input does not, then it attempts to directly input the number as a BigDecimal. If that throws an InvalidArgumentException, then it will revert back to the previous value (as with current logic).

Added two unit tests to validate the up/down with currency format as well as text replacement.

(Also included with this is adding a CSS styled BigDecimalField to the sample)

[teabeeoh]

Hi Jonathan,

thanks, I’ll have a look into that and will come back to you.

Cheers

Thomas

Am 25.01.2015 um 08:57 schrieb Jonathan Tinsman notifications@github.com:

Issue: When tabbing through a form and into a BigDecimalField, the user would normally just type in the desired number for the field. If the BigDecimalField has a currency format (i.e. $100.00), when the user types in a number (i.e. 150), it fails format validation and does not take the new number.

Solution: I have updated the BigDecimalField to check if the input matches the format. If it does, then it will use the format. If the input does not, then it attempts to directly input the number as a BigDecimal. If that throws an InvalidArgumentException, then it will revert back to the previous value (as with current logic).

Added two unit tests to validate the up/down with currency format as well as text replacement.

(Also included with this is adding a CSS styled BigDecimalField to the sample)

You can view, comment on, or merge this pull request online at:

#106

Commit Summary

Added styled BigDecimalField to demo.
Allow replacement of all text in a formatted BigDecimalField (for example currency).
File Changes

M src/main/java/jfxtras/labs/internal/scene/control/skin/BigDecimalFieldSkin.java (20)
M src/test/java/jfxtras/labs/scene/control/BigDecimalFieldDemo.java (5)
M src/test/java/jfxtras/labs/scene/control/test/BigDecimalFieldTest.java (26)
A src/test/resources/jfxtras/labs/scene/control/BigDecimalFieldDemo.css (26)
Patch Links:

https://github.com/JFXtras/jfxtras-labs/pull/106.patch
https://github.com/JFXtras/jfxtras-labs/pull/106.diff
—
Reply to this email directly or view it on GitHub.

[teabeeoh]

Hi Jonathan,

I see your point, but the problem is, that those signs (currency or
percentage sign in a percent field) are part of the format and might have a
functional role in the parsing. In the case of currency your example works
and parses correctly but in the case of percentage the parsing is not
correct anymore after your change (see the demo). I would like to stick to
the old version for two reasons:

• Any chosen NumberFormat should keep its excepted functionality when it
  comes to parsing (with the drawback that a user has to enter e.g. a
  currency sign if the format requires to)
• The BigDecimalField tries to mimic the JFormattedTextField in swing and
  that behaves like the current implementation of the BigDecimalField

As a consequence/workaround I personally do not use units within the fields
in my UIs and move them to the according field label as I agree that it is
annoying to type the unit each time you change the value.

Does that make sense?

Thomas

2015-01-25 8:57 GMT+01:00 Jonathan Tinsman notifications@github.com:

Issue: When tabbing through a form and into a BigDecimalField, the user
would normally just type in the desired number for the field. If the
BigDecimalField has a currency format (i.e. $100.00), when the user types
in a number (i.e. 150), it fails format validation and does not take the
new number.

Solution: I have updated the BigDecimalField to check if the input matches
the format. If it does, then it will use the format. If the input does not,
then it attempts to directly input the number as a BigDecimal. If that
throws an InvalidArgumentException, then it will revert back to the
previous value (as with current logic).

Added two unit tests to validate the up/down with currency format as well
as text replacement.

(Also included with this is adding a CSS styled BigDecimalField to the

sample)

You can view, comment on, or merge this pull request online at:

#106
Commit Summary

• Added styled BigDecimalField to demo.
• Allow replacement of all text in a formatted BigDecimalField (for
  example currency).

File Changes

• M
  src/main/java/jfxtras/labs/internal/scene/control/skin/BigDecimalFieldSkin.java
  https://github.com/JFXtras/jfxtras-labs/pull/106/files#diff-0 (20)
• M src/test/java/jfxtras/labs/scene/control/BigDecimalFieldDemo.java
  https://github.com/JFXtras/jfxtras-labs/pull/106/files#diff-1 (5)
• M
  src/test/java/jfxtras/labs/scene/control/test/BigDecimalFieldTest.java
  https://github.com/JFXtras/jfxtras-labs/pull/106/files#diff-2 (26)
• A
  src/test/resources/jfxtras/labs/scene/control/BigDecimalFieldDemo.css
  https://github.com/JFXtras/jfxtras-labs/pull/106/files#diff-3 (26)

Patch Links:

• https://github.com/JFXtras/jfxtras-labs/pull/106.patch
• https://github.com/JFXtras/jfxtras-labs/pull/106.diff

—
Reply to this email directly or view it on GitHub
#106.