Thanks for replying.
The blur and focusout events are only useful when the component loses focus which is not always the case.
For example, the user clicks into the textbox so they can type rather than use the dropdown. They type their date and press Enter. Focus remains on the textbox so no blur or focusout event is fired but the value is validated as the control gets error state.
Having the change event on the model rather than the control seems counter-productive. I would've expected options to validate and resolve prior to that.
If the user enters another invalid value when the control is already at error state, there's no event fired since the model is already null value from the previous error state so it's not considered a change. As above, focusout is not fired if they don't leave the textbox.
If the control was more flexible on entered date formats separate from the display date format then it wouldn't as much of a problem, but it's too restrictive. If I enter "07 Sep 2019" or "07/09/19" or "07/09/2019" or "07 Sept 19" I would expect all of those to be valid typed entries to a datepicker that displays "07 September 2019" and the control would accept and parse the entered value to set the date then display as per the display format.
I want the date to be displayed as "07 September 2019" but the user is not going to want to type that in full every time and they don't always want to use the dropdown either.
I've managed to get round this myself by handling the change event on the textbox itself instead of using the datepicker change event. Doing that means I can validate properly and accept far more variations. If the typed value is a valid date or can be parsed to one I set the textbox to the exact format the datepicker expects and remove the error state.
For example, the user can now type or "07 Sept 19", "07 Sep 2019" or "07/09/19" or "07/09/2019" or "070919" and in my handler I parse before updating the textbox to be exact format "07 September 2019".
That's the sort of inputs I would expect the datepicker to deal with by default.
It's a shame that it doesn't but now I know this is expected behaviour I'll continue handling the events on the textbox directly to remain as flexible as possible.