Can you show a screen shot of what it looks like?

volgen :)

If you are just wanting to change it on one form, that's easy. Just make a combo box with the date formats you want to use and use the After Update event to set the format. Like in the image below.

If you want to set it to apply to all forms everywhere, then your going to need to use tempvars or a settings table, and the On Current even of the forms to set the formats when you open the form.

I've seen this done with a single combo box (see picture below).  When the user types something in the combo box, its row source is updated accordingly.  A combo box also doesn't need to be requeried if the row source is a value list.  A value list is just a string, so it can be updated with string concatenation as shown in the code below.  The caveat is that the resulting entry in the combo box is text, so it needs to be converted to a date value if necessarily, with the DateValue() function.

Thanks to everyone.  I have attached a screenshot of the field.  I think Kevin's solution is the closest as the field is actually text.

If this is for selecting a date range, then the full date format m/d/yy is all that is needed.  If the user wants to enter 5/2024, he can just enter 5/1/2024.  To enter 2024, he can just enter 1/1/2024.  All the apps and websites I've seen do it like that.  There is no need for the other choices.

Kevin, this is a government form. In some fields they want just the year. In a different field they want month and year. Finally, in yet another field, they want the full date or, if true, present. This not just one date, each of these may be different dates. The dropdown, which is used for all date fields on the form, is used to select the correct format for that field. No calculations are done on these dates, they are informational only. I was just wondering if Access could duplicate this.

If the user changes the format from month-year to month-day-year, what day will it show in the box?  If it was 5/2024 before, will it show 5/1/2024, 5/2/2024, or some other date?  That was my point in my last post.  You have to put in the full date, including the day (m/d/yy), just to accommodate the possible change to the m/d/yy format by the user.  If that's the case, then why not just always use the m/d/yy format?  That way, you don't have add the ability to switch between formats and make the user interface complicated.

Also, what platform is your app?  Is it a web app?  Your screenshot shows things that Access can't do, such as putting the label "From" inside the combo box.  The dropdown box itself is also "separated" from the combo box and has a different width.  This doesn't seem to look like Windows interface.  Access can only design pretty basic Windows interface.  If you want the exact look you see in your screenshot, you may find Access lacking.

A combo box in Access is generally used for changing the content inside the box, not its formatting.  That is what Access users expect a combo box to do.  The user may be confused if the expected behavior of a combo box is not implemented.

Regarding "no calculations on dates," dates *always* involve calculations, due to the need to check for valid date values.  You can't have users entering 13 as a month or 32 as day.  And the best way to check for valid dates is use actual date values in the fields -- using the full m/d/yy format, my original point.

Ehem... we use ISO Dates around these parts. yyyy-mm-dd FOR THE GLORY OF THE EMPIRE!

Wow, it was only a simple question to see if Access could do this. Richard has done remarkable things from Access and Access does evolve. I fully understand the purpose of a combo box. As for date integrity, when the format is changed, it only allows that format with simple error checking so it would be impossible to enter a "13" for a month. I simply was wondering if Access could change the input mask on the fly like this. I am moving on from this and most likely these forums.

I, too, asked a simple question which you didn't answer: when the user switches from m/yy to m/d/yy, what is the value of "d" you want to insert there?  And I asked it in order to help YOU with this problem.  So I don't know what you are mad at.  All my posts here are related to your question.  

To check for valid dates, the best and only way is just use actual date values.  There is practically no way you can do "simple error checking" to achieve that.  Which month is supposed to have 28 days, 29 days or 31 days?  Which year is a leap year and which is not?  Between 2096 to 2104, that is 8 straight years without a leap year instead of the usual 4 (because 2100 isn't a leap year).  It would take a ton of code just to check for valid dates, whereas you can just use actual dates and let Access check for you.

Kevin, I am not mad and I appreciate your input. I find that my questions sometimes end up with answers that go way beyond what I was asking and I would rather see these details passed on to much younger developers. I started in this game in 1968 and now I just use my skill set for my law practice as I do not find any of the commercial programs right for me. Thus, as usual, Access to the rescue. I just like to put the Legos together my way and at times attempt to push the envelope. No bad feelings here.

Thanks for clearing that up, and my bad for my misunderstanding.  As to answers that go beyond what was asked, as long as they are on topic, it's better to cover more grounds than fewer.  The only way for answers to be exactly on point is when you get them from a consultant who has full knowledge of your situation.  Here, any question is likely to be answered in a "general" way that may not always be on point.  I used to post on places like Stack Overflow or Access Forums Dot Net, where I know next to nothing about the other posters, making it impossible to write "tailored" answers.  On this site, at least I know certain commonalities among the posters, such as having taken Richard's courses, what levels they are at, etc.

That's one of the reasons why I started the badges next to your name, so I can custom tailor the responses based on the skill level of the student.

Donald, for example, I can see that you're a Developer user, so I can give you responses that involve VBA programming and I know you'll get them. I wouldn't do that for someone who just had the basic badge next to their name.

But even that doesn't say everything. For example, I know Kevin is a more advanced user, but he hasn't taken any of my courses because he doesn't need them. So it doesn't always mean that someone doesn't understand VBA, but at least if I see the Developer badge there, I know they do (or should) understand some VBA.

Giving too much information in an answer isn't usually a bad thing, but sometimes you can take a newbie and confuse the hell out of them if you don't bring it down to a level they understand. That's what I try to do in my beginner lessons. That's why, with most of my TechHelp videos, I try to come up with a beginner solution first. Sometimes that's the harder thing to do. It's easy to just fire off some code to fix a problem, but to come up with an elegant, non-VBA way to fix some problems can be tricky.