I like to use the “units” or “suffix” properties of the numeric label component for displaying my process values with the units in the same field. Unfortunately, the numeric text field component used for entering set points doesn’t have the same options. We discovered that we can manipulate the decimal format string for the component to add units. This appears to work fine in most cases.
However, when we have a set point that has units of percent, this approach doesn’t work out. When I try to force the numeric text field component to display units by adding a “%” symbol to the decimal format property, it interprets the number as a percentage and multiplies it by 100. You might think a solution to this is to scale the tag as 0-100 raw = 0-1. This makes the numeric text field display a correct percentage, but it doesn’t work for input. The numeric text field multiplies by 100 when displaying but does not divide by 100 when the user enters a value. So, if a user enters 12, a value of 1200% is sent. If the user types in .125, then a value of 12.5 percent is entered. If the user enters 12.5 and the % sign, then it is handled correctly. I would like to be able to display the units but not require a user to enter them when entering set points. We need the interface to be intuitive, so the operator shouldn’t have to treat % set points different than others.
Is there some workaround where I can use an escape character or something so the % symbol isn’t interpreted to re-format the number? I’ve tried putting spaces and other characters in there, but if it sees the % symbol anywhere it formats as percentage.
As a feature request, it would be nice to be able to either have a flag to allow input to the numeric label component or add some of the features of the numeric label to the numeric text field (e.g., prefix, suffix, image path, disabled image path, etc.).
Hi there Ignition Forum,
I am re-posting to this thread. I’m not sure if the change is due to version 7.3.4.587-beta2 or it has to do with the fact we are using the on-screen keyboard, but I am finding new problems with this. I still like my numeric displays to look like my numeric set point entry boxes and I have the units displayed in each (sure wish the numeric entry component had a units field). As in the past, we have appended the units to the numeric format string and this works well except for %. To get % to display correctly, we enclose it in single quotes. This now works well for the display, but does not work for numeric entry. When you enter a number into a field with this configuration (format string = #,##0.0 ‘%’), the result is divided by 100. So you need to enter 7800 to see 78% displayed and written to your PLC.
Problems also arise if your units are seconds abbreviated as “sec.” In this case, the field remains highlighted but your entry just disappears. It never is written to the PLC (you get no dashed outline) and no error message. If I change the units from “sec” to “s”, then it works correctly and data entry is possible. If I change the units from “sec” to “seconds”, data entry is still ignored.
It looks like you are right, when you use the touchscreen numeric keypad, ‘%’ doesn’t work as it should and many of the time units stifle writes. ie: ‘sec’, ‘second’, ‘seconds’, ‘minute’, ‘minutes’, etc.
The number format fields are not meant to hold units. They are strictly for the formatting the double value. However, you can use a single quote to put characters in the format like:
#,##0.00 ‘%’
should give you a percent sign. You can look at the Java docs here:
As Robert pointed out, the single quotes approach works fine, except when using the pop-up numeric keypad. When you use a touchscreen, results become erratic. It tends to ignore new values if the initial numeric entry component includes units (in single quotes or not). If the units are % within single quotes, then you have to enter 100x the desired value to have the correct value written to the PLC. If the units are ‘sec’ it fails silently, but it works if the units are ‘s’.
The numeric keypad pop-up shouldn’t behave differently than entering values with a mouse and keyboard. When do you think this bug will be fixed?
As a feature request, it sure would be nice to have the same features on a numeric entry component as we have on a numeric display component (e.g., units, prefix, suffix, image path, etc.).
Well, problem with numeric text field:
We have to use ‘comma’ as decimal delimiter and using ‘,’ is ok. But due to “human factor”,
we must be ready for the situation, when operator puts ‘point’ instead of comma. In this case the wrong number is stored.
Examples:
If 12,34 is entered, then it is allright
If 12.34 is entered, then 1234 is stored.
We have tried to overcome the problem by casting number to the string and looging for the ‘.’ mark inside. It does not work. Are there any convenient ways or the only possible solution is to use text field instead of numeric text filed?
If you want to catch both comma ","and dot “.” and treat them the same, then you are going to have to use the text field (alpha) component and write that script yourself.
I simply do not want numeric field to behave like 5.56 --> 556. Catch both comma and dot is not needed. Let it be only ‘comma’ allowed, but in case of ‘.’ the update could be cancelled or smth. Could it be called bug?
How the comma and period are used is dependent on the locale which is set in java. If you just want to not allow the user to type a period, you can use this code in the Numeric Text Field’s keyTyped event. if event.getKeyChar()=='.':
event.consume()
event.consume didn’t do the trick, but you gave us idea, how to cancel the update of numeric text field. Thank you! Now, if user tries to insert the ‘.’ char, then the messageBox appears and the numeric text field stores the previous value.