I was trying to find ways for the client to enter time into a field and I discovered “formatted text field”. On the formatted mask, I put ##:## am this enables the client to put 4 digits, the hour and the minute(if the client enter 1248, it will display as 12:48 am). This is great, but is there a way to restrict the range of number they can put in these #s? I want the first ## to be between 0-12 and the second ## to be between 0-59. If not, what is a good way to implement this?
You could put in a property change script, so that if the value changes and it’s valid, then the value is forwarded to your destination, but if the value changes and it’s invalid, then the value is rejected and reverts back to the previous value.
It might look something like this…
if event.propertyName == "value": #print event.newValue newText = event.newValue.split(":") value0 = int(newText) value1 = int(newText) if (0 < value0 <= 12) & (0 <= value1 <= 59): system.tag.write("destination tagpath", event.newValue) else: event.source.text = event.oldValue
Also, I might uncheck “Allows Invalid Text”.
Also, attn: Ignition Devs,
I wasn’t able to get the above script to work on a Formatted Text Field by using “text” as the propertyName. I ended up just putting this into my property change script to find out what it was supposed to be:
if event.oldValue != event.newValue: print event.propertyName
and this was the output when I changed the value in the text field:
value textValid committedValue
but the tooltip on the “text” property in the property editor says that the Property Scripting Name for that property is “text”, and there is no accessible property with the name “value” as far as I can tell.
You could use a Regular expression such as
(1[0-2] #allows 10-12 |[1-9]) #OR allows 1-9 : [0-5][0-9] #allows 00-59 (\\s)?(?i)(am|pm) #allows lower or upper case AM or PM with or without a space
There are quite a few different variations of time regex patterns. A quick search will give you more options.
The formatted text field with a regular expression is definitely the easiest way to solve this.
This looks to be a consequence of the structure of the base JFormattedTextField, but I’ll make a note to investigate deeper.