Results 1 to 2 of 2
2002-05-29, 08:41 #1
- Join Date
- Nov 2001
- Thanked 0 Times in 0 Posts
Access Date formats vs NT Regional Settings (Access 97/NT4)
I've got a form with an unbound Textbox control to take user input of a date, which will be passed to a query. (I've set the default to today's date.) I set the textbox's Format to "dd/mm/yy" and set its Input Mask to match (dd/mm/yy;0," "). These _happen_ to match the NT Regional Settings' Short Date on my machine, and the form and the query do what they're supposed to.
Now I roll it out to a user, whose NT Short Date style is different. Two things happen. One is that the Format and InputMask properties are automagically changed, replacing my slash separator with the space that the user's Short Date happens to have. I can fix this by changing it back again after installation, but I don't think I should have to.
The second thing that happens is that although the dates are initially displayed according to the Format property, as soon as the user clicks in the box the display changes to their NT Short Date style (for instance with three-letter month abbreviations). Now the user is confused about the style required for input. If they type in the date in the style displayed, it conflicts with the InputMask and may not work in the query. Obviously, I could change the Input Mask and the Format to match whatever the current user's NT Short Date style is set to, but this wouldn't survive them changing their Regional Settings or work for another user who happens to have different Regional Settings.
Does anyone have a robust, user-friendly solution to this?
2002-05-29, 09:54 #2
- Join Date
- Mar 2002
- Thanked 28 Times in 28 Posts
Re: Access Date formats vs NT Regional Settings (Access 97/NT4)
Although Microsoft has done its best to support international use, its applications deep down expect everybody to use the US system.
You might read the system settings (probably need Windows API calls for that) in the OnLoad event of the form and change the InputMask and Format properties accordingly.
In my own databases, I've given up on the InputMask property for dates. I always leave it empty. Wherever possible, I set the Format property to the built-in ShortDate, so that it will conform to the user's settings. Setting a date-related format automatically acts as input validation - entering an invalid date results in an error message.
Another possibility is creating separate text boxes for day, month and year. You can assign numeric input masks for them and set the AutoTab property to True, so that the user doesn't have to tab from one text box to the next.