allowing text date entry with no "/"s
I've got a date field setup for user entry where I want to allow the users to enter a date with no "/"s ie: 01011990 and allow the application to convert it to 01/01/1990. In the property edit under Validation for Edit input I have AutoDateFormat to do the conversion. However the invalid date error msg still displays. If I a cell property action with a change event and a refresh-this section action then the error message will briefly flash on the screen, the date format will convert to have "/"s and the date will redisplay with no more error message. Is there a way to allow this input format without triggering the error message at all?
EvonSys India Pvt Ltd
AU
As I understand, you are trying to enforcing two contradictory conditions on same property one is not allowing to keydein '/' in and another way need to format the date to '/' . Hence these resulting display error message all the time on the screen
Do one thing, use some temporary property for keyin date(01011990) and copy that date to some other property where you need to format(01/01/1990) as required.
Updated: 25 Aug 2021 23:32 EDT
Rulesware
PE
Hi EricK145,
The problem with the edit input rule is that it requires an HTTP communication with the server passing the Date field as part of the HTTP request. But, in order to pass the Date value, it will try to set it first (on the input field, pure HTML not Pega), at this time, the value has no slashes "/" in it (those will be inserted in the server by the edit input rule), so the validation fails.
If this requirement is absolutely necessary, then I would proceed with JavaScript. You will find many examples on the web to manipulate the input value (like https://stackoverflow.com/questions/5005877/whats-the-best-way-to-automatically-insert-slashes-in-date-fields). The field validation will occur when the OnChange event occurs (ex. click outside the field), at that time the date value will be formatted properly (with the slashes "/").
I am not fond of JavaScript but in this case I think this is a valid solution with no impact on peformance.
Anyway, please try to reconsider that requirement and utilize the standard Pega date field.