Yes. I came to that same conclusion. The mask would have worked, but for the unexpected side-affects. I give up. Thanks anyway.
Yes. I came to that same conclusion. The mask would have worked, but for the unexpected side-affects. I give up. Thanks anyway.
The masks can cause issues. i develop for some heavy data-entry people and they like them. They whine about any extra keystroke. That said, there may be code-based solutions that would give you the best of both worlds.
If so, any suggestions how I might find such possible solutions, or where you thinking I might come up with on (not likely)?
I haven't tried this, and I'm not sure this will work, but you may check out Change event of textbox control (it is fired with every keystroke, and also when control contents are changed, so you have to ensure, the event code is not resulting as cascading). Theoretically it is possible the event checks contents of textbox after keystroke for length of entered value in textbox, and corrects current value string according certain rules (E.g. when the 2nd entered character is "/", it ads leading "0" as 1st character, when 3rd entered character is number, it adds "/" as 3rd character, ..., until when 12th character is number, it adds ":" as 12th character). But data entry into textbox may slow down considerably.
In case this will work, you can enter e.g. 010120191230 or 1/1/20191230, and the entry will be 01/01/2019 12:30
Edited: ... when 14th character is number, it adds ":" as 14th character).
Last edited by ArviLaanemets; 08-24-2018 at 12:27 AM.
I presume, when you say Textbox, you don't mean a date/time control. I use this control to sort events and other items, usually in descending order. I also choose the most recent data to display, all based on the date or date/time. It would be a major reconstruction to change from Date/Time to a standard text box. I have been thinking about trying to invoke some Event control to get around the unexpected side-affects of using a mask, noted earlier in post #7. I wonder if some of the things you are talking about might apply to the Date/time control, using a mask?
I mean Textbox control on form, formatted as date, with date field as a source. The control may have default value, e.g. current datetime (and the change event must then probably be starting with If ... Endif clause to check the entry length to be less than 14).
I guess I do not know enough to implement what you are describing. The mask only fires when one enters an empty field. Once it has a date, it won't work anymore. The mask will not allow modifications to the existing date. And when one deletes the date to start over, the mask does not activate until one exits the field and re-enters it after deleting the data. I guess I'll just stick with entering the ":".
I suppose one work-a-round would have been to create the fields as text, not dates, and then apply a text to date conversion function in form and report queries that need to deal with it as a date.
I really don't recommend using the Change event. As Arvil stated it fires after each keystroke so that means it will fire 12 times when entering this 010120191230 to get 01/01/2019 12:30I guess I do not know enough to implement what you are describing. The mask only fires when one enters an empty field. Once it has a date, it won't work anymore. The mask will not allow modifications to the existing date. And when one deletes the date to start over, the mask does not activate until one exits the field and re-enters it after deleting the data. I guess I'll just stick with entering the ":".
I suppose one work-a-round would have been to create the fields as text, not dates, and then apply a text to date conversion function in form and report queries that need to deal with it as a date.
As well as making text input difficult to read, it will I believe result in performance being very poor.
Yes you could use text fields rather than dates as I previously mentioned but personally I wouldn't do that either.
You'll be making lots of work for yourself by doing so
If you are absolutely desperate to do this, you could use 5 combo boxes for data input (all using value lists) for the month, day, year, hour and minutes (as on a smart phone).
Then combine those using VBA to give the full date/time value in your date field and display in your chosen format
I guess I am not that desperate. By the way, I suppose everyone is aware that Access does not honor the 2 digit hour specified in the date/time control format property. Other than using the Format() function, which, I believe, won't work for data entry in a form, there seems to be no way to get Access to honor the 2 digit hour. I presume that is a system bug in Access.
Fair enough but it would be easy enough to setup
You said that before but I couldn't replicate it in my tests. Perhaps you could give an example that illustrates your pointBy the way, I suppose everyone is aware that Access does not honor the 2 digit hour specified in the date/time control format property. Other than using the Format() function, which, I believe, won't work for data entry in a form, there seems to be no way to get Access to honor the 2 digit hour. I presume that is a system bug in Access.
.
But do remember, Access stores dates as double number datatype no matter how they are displayed.
Its currently 24/08/2018 21:52:34 in the UK. As far as Access is concerned that's CDbl(#24/08/2018 21:52:34#) = 43336.9115046296
I can write that as e.g. Cdbl(#8/24/2018 9:52:34 PM#) or Cdbl(#2018-8-24 9:52:34 PM#) but it still gives the same result
Yes. But it has never changed. I have attached an image of one of my Events, a callout for a forest fire in Utah. As you can see, any hour less than 10 is only one digit. The Format property is:
mm/dd/yyyy hh:nn
with no quotes. I can use HH:nn and HH:mm, or hh:mm, and it makes no difference. The only way I can get it to show 2 digits in reports is to use the Format() function.
Also, I would like you to note the gray bar at the very bottom of the image. Access often puts it there for no apparent reason, which partially covers up the Assignments window. It does the same on other other navigation tabs, also. Sometimes, it is not there, but most of the time it is. This takes away from the usable vertical space, and I have no clue why it does that. In case you are wondering, no, it is not a scroll bar. I guess I said that wrong. It is on the base navigation form, on which all the tab forms are placed.
I understand how the dates are stored. When I was programming in Clipper (xBase), I created calender and date objects which managed dates using the Julian day number, used by scientist, etc. The calendars went from 4713 BC to 4K AD. I even designed it to handle partial dates, which Access cannot do, but which would be handy to do at times. With the Julian Day Number, I could convert from one calendar system to another. These applications were related to Genealogy Research.
![]()
As already stated, I can't replicate this issue.
Here are two different forms (datasheet & continuous) with the same data.
No special formatting has been applied - its just the default General Date. Try that!
BTW: always use nn for minutes as mm is for months
As for your other issue with a 'phantom grey bar' at the bottom. I've seen similar design glitches & they can be difficult to fix.
Check its not just a footer section in your main form
If not, try changing from tabbed windows to overlapping windows in Access options
I want to avoid using the General Date format, as it includes seconds and AM/PM and wastes a lot of space on the forms and reports, that is not needed. The only way I know how to avoid that, is to do the mm/dd/yyyy hh:nn in the format property. However, Access, oddly, won't honor the format for the hour. It has done this for years through many version of Access and Windows.
I tried changing Tab to overlapping under options, closed the program and reopened it. It only changed the main form from tabbed to overlapping. All the tabbed Navigation sub-forms remain the same. And the gray bar is still there.
At the risk of repeating myself, the format dd/mm/yyyy hh:nn also works fine for me
Correct. That's what is meant to happen.I tried changing Tab to overlapping under options, closed the program and reopened it. It only changed the main form from tabbed to overlapping. All the tabbed Navigation sub-forms remain the same.
Re: 'grey bar' Try switching navigation buttons off. Any help? Switch back on again. OK now?
Does your form have a footer section? If so try removing it