Cstr() is such a nice-looking innocent function. An easy way to get a string representation of a date. The atom bomb hidden inside it is that the format of the date is determined by the regional settings on the computer running it. That means that its output is unpredictable. We have clients in several countries and usage of this function has caused us and our clients untold grief tracking down “it works on all the computers except for this one” type problems. Of course we cannot recreate said problem because all of our computers have the same regional settings.
This is not a problem for many developers but it should definitely always be in the back of your mind. In our shop we have banned the use of Cstr() and must use Format() instead because you have control over the format of the result. In this example, what if the regional settings of the computer resulted in a date string that violates file naming rules?
I am not being nitpicky but hopefully this post can save someone else the hair-pulling and aggravation that we have been through in our dance with the Cstr() function.
Thanks for posting the information regarding Cstr(). I would think you would run into the same problem with the format statement if you passed an invalid date to it.
You never use Cstr? What about for a simple convert for programming purposes?
Dim TmpNumber as Double ’ where FieldName is defined as number
Dim sTmpNumber as string
TmpNumber = Doc.FieldName(0)
sTmpNumber = Cstr(TmpNumber)
Do you see any problems with the use of cstr in this case?