# NumericTextField Decimal format **URL:** \ **Category:** Ignition\ **Created:** [April 14, 2015, 9:57am UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907 "2015-04-14T09:57:16Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![r.lebohec](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/r.lebohec/32/3704_2.png) [@r.lebohec](https://forum.inductiveautomation.com/u/r.lebohec)\ **Post date:** [April 14, 2015, 9:57am UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/1 "2015-04-14T09:57:16Z")
In our country we have Decimal separator ‘,’ and ‘.’ for the thousands. When i use numerictextfield component with a float value, it show value like ‘12.88’ and I must enter ‘12,88’ for a valid change value otherwise it understand ‘1288’ Is it a way to standardize display and input value with the numerictextfield? ---
**Author:** ![glogue](https://avatars.discourse-cdn.com/v4/letter/g/9fc348/32.png) [@glogue](https://forum.inductiveautomation.com/u/glogue)\ **Post date:** [April 14, 2015, 2:18pm UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/2 "2015-04-14T14:18:57Z")
In the property editor for the numeric text field, you can change the decimal format to a format you’d like. ---
**Author:** ![KathyApplebaum](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kathyapplebaum/32/7261_2.png) [@KathyApplebaum](https://forum.inductiveautomation.com/u/KathyApplebaum)\ **Post date:** [April 14, 2015, 2:28pm UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/3 "2015-04-14T14:28:54Z")
A little additional information… In some areas of Ignition, the number formats change automatically based on the locale. However, on components like the numeric text field where there was already an option to choose your own number format, we decided not to override that selection. Unfortunately, this means that you a) need to remember to update that property when you place a component and b) change the property through scripting if you’re dealing with multiple locales. ---
**Author:** ![Amarth](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarth/32/3313_2.png) [@Amarth](https://forum.inductiveautomation.com/u/Amarth)\ **Post date:** [January 29, 2016, 11:08am UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/4 "2016-01-29T11:08:13Z")
Hello, I have an identical problem. Changing the decimal format property does not work as “##0,#” is seen as an invalid format string (Malformed pattern). Using the dot “.” of the numpad does not work and is simply ignored for the value. (ie. 5.3 becomes 53) Is there a decimal pattern that could make the use of the numpad decimal separator valid ? Thanks in advance. Ignition 7.8.0 Java 64 bits Windows Locale : fr ---
**Author:** ![KathyApplebaum](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kathyapplebaum/32/7261_2.png) [@KathyApplebaum](https://forum.inductiveautomation.com/u/KathyApplebaum)\ **Post date:** [January 29, 2016, 4:09pm UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/5 "2016-01-29T16:09:38Z")
Because we allow users to change locales on the fly, we don’t use localized format patterns. Every where you see a format pattern, you should use the dot to indicate the decimal separator for your locale, and the comma to indicate your locale’s thousands separator. So “##0,#” would definitely be a malformed pattern, since you can’t have a required digit to the left of a thousands separator and optional digits to the right. I can’t replicate the issue Amarth is seeing with 5.3 becoming 53, but I did see a few issues with how the component treats numbers in a French VM, especially when changing locales or changing format patterns. We’ve done some more work on the number formatting and localization for this component in 7.8.1 and 7.8.2, and I wasn’t able to find any current problems in 7.8.2 (again, running in a French Linux VM, java 8u72 64bit). I don’t have a release date for 7.8.2, but I expect the beta will be up very soon, with the -rc soon after. ---
**Author:** ![Amarth](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarth/32/3313_2.png) [@Amarth](https://forum.inductiveautomation.com/u/Amarth)\ **Post date:** [February 1, 2016, 8:48am UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/6 "2016-02-01T08:48:49Z")
Thank you for the reply. I used a workaround for this problem. It does the trick, event if it is not very elegant. In the keyTyped event of the numeric text field: `if event.keyChar=='.': event.setKeyChar(',')` Regards. ---
**Author:** ![Plantformance](https://avatars.discourse-cdn.com/v4/letter/p/b77776/32.png) [@Plantformance](https://forum.inductiveautomation.com/u/Plantformance)\ **Post date:** [April 9, 2018, 1:55pm UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/7 "2018-04-09T13:55:58Z")
Dear Kathy, Problem still exists and is very annoying. Basically what we observed is that the conversion to float/double does not take care of the “locale” for the decimal point, so a soon as you are on a locale that uses “,” as decimal it will not work. Worse is that the comma is not even interpreted as thousands also but something in between. 7.9.6/linux server, windows 10 client regards, ---
**Author:** ![KathyApplebaum](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kathyapplebaum/32/7261_2.png) [@KathyApplebaum](https://forum.inductiveautomation.com/u/KathyApplebaum)\ **Post date:** [April 9, 2018, 1:57pm UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/8 "2018-04-09T13:57:44Z")
Can you contact support with this? ---
**Author:** ![Plantformance](https://avatars.discourse-cdn.com/v4/letter/p/b77776/32.png) [@Plantformance](https://forum.inductiveautomation.com/u/Plantformance)\ **Post date:** [April 9, 2018, 1:58pm UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/9 "2018-04-09T13:58:34Z")
Sure will do. thanks ---
**Author:** ![Sanderd17](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/sanderd17/32/8735_2.png) [@Sanderd17](https://forum.inductiveautomation.com/u/Sanderd17)\ **Post date:** [February 20, 2019, 10:51am UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/10 "2019-02-20T10:51:26Z")
This issue still exists, but it’s an inconsistency between the locale used, and the keyboard layout. Although many European languages officially use comma as a decimal separator. Software is mostly English based, so most software historically only accepted the period as decimal separator. This is still true for a lot of software. And certainly programming languages always use the period as decimal separator. As a result, many keyboards put a period on the numpad. So inputting numbers into software works as expected. See f.e. the Belgian AZERTY layout that uses a period. ![](https://us1.discourse-cdn.com/inductiveautomation/original/2X/1/19aa1ef5b82f5b64ac4c6c0c231c49333a9d85e8.png) This does create an awkward situation, where on one hand, localised software wants to display the correct number format, but on the other hand, the numberic input of decimals should still be easy on the numpad. This awkward situation also caused some issued for German and Polish users when Windows changed that key from a period to a comma. See f.e.: [windows 8 - Dot instead of comma on numerical keyboard - Super User](https://superuser.com/questions/747250/dot-instead-of-comma-on-numerical-keyboard) The only solution is to let users decide independently from the language. F.e. Excel lets you choose the separators separately: [Change the decimal point to a comma or vice versa - Microsoft Excel 2016](https://www.officetooltips.com/excel_2016/tips/change_the_decimal_point_to_a_comma_or_vice_versa.html) At the moment, we have the choice between setting Ignition in English (which causes the localisation tooling to not work), or reach to the alphanumeric part to type a comma as decimal separator, or putting the script above on every numeric component (and remembering to remove it when we have a project in the UK). PS. I tried setting the numeric format in Java (like described here: [java - Decimal separator in NumberFormat - Stack Overflow](https://stackoverflow.com/questions/4713166/decimal-separator-in-numberformat)), but that didn’t change anything AFAICS. PS2. I know for the specific case of Belgium, there exists also a “Belgian comma” layout, that puts a comma on the numpad. However, I’ve never seen a keyboard in the wild with a comma printed there, and it also breaks other software, certainly programming languages. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [February 20, 2019, 4:18pm UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/11 "2019-02-20T16:18:12Z")
While it’s slim consolation, because clearly this is a problem actively affecting users, we do have a ticket on our internal backlog to do just what you’re suggesting, @Sanderd17 - add a setting to allow the the designer to change the behavior of the number pad’s ‘decimal separator’ key, in order to support both possible options here. ---
**Author:** ![jeffrey.boey](https://avatars.discourse-cdn.com/v4/letter/j/6a8cbe/32.png) [@jeffrey.boey](https://forum.inductiveautomation.com/u/jeffrey.boey)\ **Post date:** [November 27, 2020, 12:35pm UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/12 "2020-11-27T12:35:00Z")
Hi, apologies if I’m not suppose to necro this thread. I encountered the same problem in Ignition 8.0.13. I’m currently developing a view for a french client, and for all numerical inputs they have to use the comma on the main keyboard instead of the period on the keypad, this does cause some confusion especially with new users who are not aware of this and enter the values too fast. (0.1 becomes 1 for example) Is there a workaround for this? I’ve been looking around but I have yet to find a solution. Thank you very much. ---
**Author:** ![petr.sasin](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@petr.sasin](https://forum.inductiveautomation.com/u/petr.sasin)\ **Post date:** [January 4, 2022, 8:20am UTC](https://forum.inductiveautomation.com/t/numerictextfield-decimal-format/9907/13 "2022-01-04T08:20:39Z")
Thank You. This work around works very well for me. Issue is the keyboard settings in Windows. In my configuration I have Windows local settings set to Czech with decimal separator **,** (comma). It is same like i.e. German or French. But I use two different keyboard layouts - English (_EN_) and Czech (_CS_). If I switched to _EN_ keyboard decimal separator on Numpad is **.** (dot) and entering values in numeric text field was working well from Numpad. If I switch to _CS_ keyboard then decimal separator on Numpad is changed to **,** (comma) and I was not able to enter decimal point from Numpad. I had to use **.** (dot) on regular keyboard. It seems that numeric text field requires always **.** (dot) as decimal separator for entering of decimal values regardless of local Windows settings. But when You finish entry (with ENTER or TAB or simply by clicking somewhere else) then decimal separator is automatically changed to decimal separator set in Windows local settings (in my case **,** - comma) and is displayed correctly. Igntiion v 7.9.18