<
[email protected]>:
Some comments inline
Actually the DefaultValue property of a control is always a string
expression regardless of the data type, so whether it’s a number,
text or date you simply delimit it with literal quotes:
Me.txtNameOfControl.DefaultValue = """" & Me.txtNameOfControl & """"
I didn't know that - but some additional comments - this would also
work where I live, for text of course, but not necessarily for dates
and numbers.
And - what I posted for numerics in my first reply, actually doesn't
work, either, if the number contains decimals (should have tested).
The below, however, works
Me!txtNameOfControl.DefaultValue = _
Replace(Cstr(Me!txtNameOfControl), ",", ".")
Dates are the one which often catch people out because if they put
Me.txtNameOfControl.DefaultValue = Me.txtNameOfControl
and the value in the control is in a short date format this will be
interpreted not as a date time value but as an arithmetical
expression, so today's date in European format 14/04/2007 would
evaluate to 0.00174389636273044 which is the underlying value of a
date time value of 30 December 1899 00:02:31, a date/time value in
Access being implemented as a 64 bit floating point number as an
offset from 30 December 1899 00:00:00.
But, no, on my locale, that produces #Name, because what is entered
into the Default Value property, say for todays date, is 14.04.2007,
which isn't recognized as anything sensible by Access.
By wrapping the value in quotes on the other hand, then the default
value placed in the control when at a new record is just a string of
characters, which might represent a number, a text string or a
date/time. Formatting the value as you did and wrapping it in
date/time delimiter characters would help, but assumes the value
entered is a date without any particular time of day (which in fact
would be midnight at the start of the day as there is no such thing
as a date value without a time of day in Access).
If i wanted time, I would probably add "hh:nn:ss".
The same applies if you call the Date function to set the
DefaultValue property in code. If you were to put:
Me.MyDate.DefaultValue = Date
then the result would be 30 December 1899 00:02:31 again because the
return value of the Date function is by default expressed in the
local short date format, and consequently interpreted as an
arithmetical expression. If you put:
Again - #Name, because Access doesn't understand 14.04.2007
Me.MyDate.DefaultValue = "#" & Date & "#"
then this would work in countries using US date formats, but here
only on days like today where 14/04/2007 in European format is an
invalid date in US format, so Access 'corrects' it. If the European
date is a valid US date however, then its not 'corrected', e.g.
11/04/2007 European format for 11 April 2007 is of course 4 November
2007 in US format and would incorrectly set the default value to
that date. Whereas:
Again - #Name, because Access doesn't understand #14.04.2007#
Me.MyDate.DefaultValue = """" & Date & """"
would work correctly both here and in the USA whatever the date.
BTW the differences in short date formats initially caused a lot of
problems for British and American signallers during the Second World
War (I recall when I was young one former Royal Corps of Signals
sergeant telling me how they would repeatedly request US units to
re-send signals, even though they were well aware what date was
meant!), so it was decided that in signals traffic long date formats
should always be employed.
Here, when using doublequoting, what is actually placed into the
property (again with todays date) is "14.04.2007", which Access will
happily understand as long as the locale is set to Norwegian. But,
both me and a couple of my customers, will regularly toggle these
settings during sessions (Norwegian to either UK or US), in which
case such Default Value produces #Error.
Same might happen for numbers containing decimals.
So, my reasoning with this, is to ensure the format is unambiguous,
at least as far as the interface is concerned, which makes me
reasonable sure that Access will understand it, regardless of locale,
and regardless of whether locale is changed during session.
Part of what makes it fun living in Norway, is that period is used
as date separator, and comma is used as decimal separator
