Thanks for paying it forward, Andrew. That's a handy little trick when you want to force users to pick the date with the calendar control instead of typing something unexpected into the box.

Just remember that KeyDown only blocks keyboard input. A user could still potentially change the value through VBA, a paste operation depending on the control behavior, or by editing the underlying table directly. For normal users on a form, though, it is a perfectly reasonable way to make EnterDate calendar-only.

For anything where the date really matters, I would still validate it in the form's BeforeUpdate event. The user interface should guide people toward correct data, but validation is the last line of defense. LLAP.

I get your point. I keep users well away from anything to do with the backend, tables or coding.
My scenario is that the date picker(s) are incorporated into  validation forms where the user ensures that every field, all entered via lists, dropdowns etc. are correct before saving the data to tables. The date picker is there if it's a late entry and the user needs to keep the lists correct.
When the final product is ready I have a whole load of shut off to enable.
'    FS02 "AllowSpecialKeys", dbBoolean, False
'    FS02 "AllowBypassKey", dbBoolean, False
'    FS02 "AllowBreakIntoCode", dbBoolean, False
'    FS02 "StartupShowDBWindow", dbBoolean, False
'    FS02 "AllowFullMenus", dbBoolean, False
'    FS02 "StartupShowStatusBar", dbBoolean, False
'    FS02 "AllowToolbarChanges", dbBoolean, False
If you can think of anythig else please let me know before June next year.

Are we talking about code injection?  One way to combat that is with parameter queries, in which user inputs are always treated as parameters instead of possible code fragments.

Without going into specifics everything is basically prefabricated. The user selects from a number of preset options and calculations are then rendered. In places where the user is allowed to enter criteria the text is validated by length, Ascii etc. If it meets the validation rules it's a press of a button and the underlying table and queries are updated. Of course they can enter gibberish text but that's their problem.
I would say that it's not the sort of database that is normally discussed here.

Kevin  I have replied to you in the thread.

In cases like this, when entering a date and ensuring its accuracy is important, I prefer to open my own date picker form as soon as the control receives focus. If no date is selected, I display a warning asking the user to either select a date or the record will be canceled. After that, it’s up to them.

However, rather than trying to anticipate and deal with people who deliberately try to break your code, I think a better approach is to validate the entered data at the form level, using the BeforeUpdate event.