O
Oenone
In our applications, we use the special value of DateTime.MinValue to
represent "null dates" throughout all our code. We recently ran into an
issue where we wanted an optional date parameter for a procedure. We weren't
able to declare it with DateTime.MinValue as its default value, as MinValue
is a read-only property rather than a constant. To work around, we had to
use a "magic date" that we checked for later on. I was never very happy with
that solution.
Today however I noticed that VB2005 is quite happy with the following:
\\\
Public Sub DoSomething(Optional ByVal SomeDate As Date = Nothing)
[...]
End Sub
///
(I believe this fails to compile in VB2003).
The value that is present in SomeDate if no date is provided by the calling
code is DateTime.MinValue (i.e., the default value for an uninitialised date
variable).
Is this the intended documented behaviour of declaring the optional
parameter in this way? Can I use this safe in the knowledge that the
behaviour won't break or change in the next release of VB?
Thanks,
represent "null dates" throughout all our code. We recently ran into an
issue where we wanted an optional date parameter for a procedure. We weren't
able to declare it with DateTime.MinValue as its default value, as MinValue
is a read-only property rather than a constant. To work around, we had to
use a "magic date" that we checked for later on. I was never very happy with
that solution.
Today however I noticed that VB2005 is quite happy with the following:
\\\
Public Sub DoSomething(Optional ByVal SomeDate As Date = Nothing)
[...]
End Sub
///
(I believe this fails to compile in VB2003).
The value that is present in SomeDate if no date is provided by the calling
code is DateTime.MinValue (i.e., the default value for an uninitialised date
variable).
Is this the intended documented behaviour of declaring the optional
parameter in this way? Can I use this safe in the knowledge that the
behaviour won't break or change in the next release of VB?
Thanks,