Windows 10/ Access 2016: How do you create a date field on a form?

After Access 2010 Microsoft disabled the calendar/datepicker because it has a built in in newer versions..i think you can still use it if you register it ..it should be located in the SysWow64 folder. ...and its called mscal.ocx
Hint you must register it with regsvr32 from SysWow64 not the "regular" from System 32

Thanks for that, John. So I have copied mscal.ocx into the SYSWOW64 folder and I am running the command as an administrator. However, I get an error messages saying that it 'was loaded, but the call to DllRegisterServer failed'.

did you used the regsvr32 from SysWow64 ?

Something to clear out....did the application (Access) was developed with Access 2010...because i thought it was dropped after Access 2010 but from what i read Access 2010 didn't came with the calendar control ...some maybe there is another issue

I did. I made sure I was in c:\windows\syswow64, and ran the regsvr32. Also I made certain that I was running Command as the administrator. We had ran into similar issues with other ocx files.

I have checked the references in Access 2016, and none are listed as missing. As I am not the original developer, I'm not quite sure what he had used. Comparing the references between the 2010 and 2016 versions, I looks like I have them all.

The best option is to do what you started to do.  Get rid of the OCX and use the integrated date picker.  If the control is bound, you do not need a format, Access knows it is a date.  For unbound controls, you need to specify a date format such as short date.  The control must be a textbox.  The date picker will not show for any other control type. The ShowDatePicker property also needs to be set.

Now I do not see the integrated date picker. I will attach a screen shot of what I see when I go to create a new date field on my form.
form1.jpg

Did you fill in a date format for property Format - as Pat showed, top red mark?

I guess my screenshot did not attach. I have added a screenshot to my previous comment. In that screenshot, you will see that when I bring up the Properties for the textbox, I do not get Format. For some reason, it does not show.
form1.jpg

But that is a UserForm - as used in Excel and Word - not an Access form.

Remove that and recreate it as a true Access form.

So are you saying that I cannot create a date field in a UserForm? The reason I'm asking is that there are a number of tabs on this form, with all the associated code. So if I cannot create a date field in a UserForm, this becomes a bigger issue.

Is there a way to convert a UserForm into a true Access form?

I'm not saying that you can't, but UserForms are a sort of poor-man-forms, not intended to be used in Access as the Access forms are superior and, in any way, optimised for Access.

The datepicker option seems to be one those features missing in UserForms.

No, there is no way to convert a UserForm to an Access form.

If only your data is in an Access database (actually Jet or ACE and NOT "Access" at all), then you are not using Access.  Access is a RAD (Rapid Application Development) tool that is used to build applications.  Jet (.mdb) and ACE (.accdb) are the desktop databases that are frequently confused with Access the RAD tool because Access the RAD tool uses those databases to store its own objects.  Access the RAD tool can use ANY RDBMS that supports ODBC to store data.  It is not restricted to using Jet and ACE.

It seems that you are using something else as the FE to your database and it is creating UserForms.  As Gus told you, they are quite inferior to Access forms and there is no direct conversion path.  If the UserForms are using VB code, you can probably copy a lot of the code and reuse it although you will need to be carefull with control and form properties and events since they are different in the two object models.

Thanks to you all for your help. This system was created as a summer project by university students and is slated to be replaced in the near future, so we were hoping to find a quick solution that would tide us over until the new system came online. Doing a bit more digging, we have discovered possibly how the forms were created and perhaps a solution. I will outline our plan here and if you have any suggestions/tips/hints/warnings, please let me know.

We think the form was written in VB6 and then imported into Access. So if we export the form out, make the changes, and then re-import it, we may be good. Otherwise, we may have to move the form into VB.NET and then make changes there and import that.

I would expect it to be far simpler to just recreate the form as a native Access form.

I agree with Gus.  Vb.Net is more different from VB and VBA than you might imagine.  I seriously doubt that you would be able to import a VB.Net user form and I am mystified as to how a VB6 userform was imported into Access.  Anyway you can post this database so we can look at it?