CDate function returns 'IndexOutOfRange' error - also in VB.Net 2005 Beta2
Hi folks,
I have already reported this error in the VS 2005 Beta2 forum, but was told that it was not reproducible (VbCity and VBug, and your UK Launch team were also unable to reproduce the problem). I think I now have a lead on the issue!
It also looks similar to a problem reported yesterday on the VB Express forum - 'I keep getting the out of range exception'.
I have condensed the problem to two lines of code:
Dim myDate as DateTime
myDate = CDate("01/01/2005")
The above error is reported on execution of the second line.
This has now occurred on 6 different (otherwise successful) installations:
a) VS 2005 Beta2 (VB):
1. Desktop PC 2.4 GHz P4, 1 Gbyte RAM.
2. Desktop PC (same) running a clean new install of XP Pro SP2 under a Virtual PC.
3. Toshiba A10 laptop (XP Pro)
4. HP compaq nc4000 (XP Pro)
b) VB Express:
5. Desktop PC (as above), running under Virtual PC 2004: Beta2 above removed per MS instructions (first removed all SQL Express 2005 modules, then used MS automatic tool). No errors reported for Express installation.
6. Dell laptop Inspiron 8000 running Windows 2000 Pro. No installation errors.
Finally I had an inspiration - I use a PCMCIA hard-drive card to saveall my VB6 / VB.Net projects on, as I work from several locations, one being Austria.
Thus the common thread between all of these installations is that I have a PCMCIA card reader installed in all cases, including the Desktop!!!
Thus I then re-formatted a spare hard drive for the desktop, DISABLED my PCMCIA reader, and installed a new clean copy of XP Pro, followed immediately by my copy of VB Express 2005 (downloaded yesterday).
Low and behold, the problem disappeared!
Now I simply need a fix to cure the interference on the first 6 installations noted above! I downloaded 'Express' ahead of my RTM version of VS 2005, as I was not convinced that the problem would have been sorted - looks as if I was right.
Hope you guys can help, as I rely on my PCMCIA card drive to synchronize all my work.
Best Regards,
Dr Keith Bromley
Just a guess, but is it possible that the culture settings for your application are different than locale settings on the computers where you are getting the error? Since you mentioned that you sometimes work from Austria, I would assume that the locale settings for the installed version of Windows there are German, not English, and the Date format would be different.
CDate recognizes date formats according to the locale setting of your system, and you must provide the day, month, and year in the correct order for your locale. The topic "Type Conversion Functions" discusses this in the Behavior section:
http://msdn2.microsoft.com/en-us/library/s2dy91zy.aspx
Hope this helps,
Steve Hoag
Visual Basic Express
Steve's right. The short date format in Austria is 'dd.mm.yyyy', therefore your date should '01.01.2005' not '01/01/2005'.
Check your regional settings via Control Panel -> Regional and Language Options.
Thanks for your speedy reply!
Unfortunately, your recommendation is the first thing I checked on receiving this error.
In fact, ever since VB6 I have been wary of Date formats and the confusion that UK/US dates cause. Hence I always set ShortDate Format to 'dd mmm yyyy', wherever I am.
I tried all the different date formats I could think of, always with the same result.
At the time of the OutOfRange exception, I get the following message in the Immediate Window:
'A first chance exception of type 'System.IndexOutOfRangeException' occurred in mscorlib.dll'
The only way I have avoided the error is via the clean installation without the PCMCIA reader (desktop), but this is hardly possible with my laptops, when the driver is already pre-loaded.
Hope you might be able to reproduce the error now, and maybe find a solution.
Thanks and Regards,
Keith Bromley (UK)
I really find it hard to believe that the PCMCIA reader has anything to do with it, although I have seen stranger things ;-)
I notice in your original post that this problem was occurring using Beta 2, and that after installing Visual Basic Express (I'm assuming the RTM version, not the Beta) the problem went away. I'm wondering if your problem might have been a bug in the Beta version of the VB runtime?
- Steve
Thanks once more Steve!
You are right, it's not the PCMCIA; however I finally have a handle on how to reproduce the error:
You may have noticed that I prefer to use the ShortDate format 'dd MMM yyyy'; therein lies the problem!
My clean installation that worked without the PCMCIA enabled had the Locale set to English (UK), and the default SDF 'dd/MM/yyyy'. The code then works, whether the date entered is "01/01/2005" or "01 Jan 2005".
However, on changing the default SDF to 'dd MMM yyyy', then an entered date of "01 Jan 2005" or "01/01/2005" both fail with the reported 'IndexOutOfRangeException".
I have now checked this out on the English (USA) Locale, and have again reproduced the error conditions: .Net simply does not like the setting being changed from default to 'dd MMM yyyy'!
As using this setting is now my only option to provide continuity on migration from earlier VB6 production programs (and avoid USA/UK confusion), I need a way of overcoming this issue.
Hope you can now reproduce my scenario, and hopefully, suggest a solution.
Kind Regards,
Keith Bromley
PS. I'm travelling to Austria tomorrow, so won't be able to communicate again until Thursday.
Keith -
The following comes from the Type Conversion Functions topic:
"If you need to convert to or from a string representation of a value in a format other than the one specified by your locale, you cannot use the Visual Basic type conversion functions. To do this, use the ToString(IFormatProvider) and Parse(String, IFormatProvider) methods of that value's type. For example, use System.Double.Parse(System.String,System.IFormatProvider) when converting a string to a Double, and use System.Double.ToString(System.IFormatProvider) when converting a value of type Double to a string."
Unfortunately no example code, but I think what it's trying to say is that instead of using CDate you should create your own type conversion function by implementing IFormatProvider.
Hope this helps,
Steve Hoag
Nah, you won't have to go that far, simply use DateTime.Parse and DateTime.ParseExact.
Steve, Dave – thanks again;
I have now adapted the example given in Help files ‘ DateTime.ParseExact Method (String, String, IFormatProvider)’ to enable me to read dates inputted as strings.
However, the behaviour here is STRANGE in the extreme!!!
My Locale = English (United Kingdom)
ShortDateFormat (overwritten from default) = dd MMM yyyy
However, to avoid the same error I had previously reported to you, I had to use the French culture as per the example (en-GB fails for the above situation, as does de-DE). Also when I change the input date string to “16 Feb 1992”, then DateTime.Parse works OK, but DateTime.ParseExact fails!
A little explanation from you would be of great help! Also, I would prefer to remove the time stamp of 00:00:00 that I get when I omit the time in my string entry.
(modified) Code from above Help file:
' Reverse month and day to conform to a different culture:
Dim culture = New CultureInfo("fr-FR", True)
Dim myDateTimeUKValue As String = " 16/02/1992 12:15:12"
Dim myDateTimeUK As DateTime = DateTime.Parse(myDateTimeUKValue, _
culture, DateTimeStyles.NoCurrentDateDefault)
Console.WriteLine("2) myDateTimeUK = {0}", myDateTimeUK)
' The date is Feburary 16, 1992, 12 hours, 15 minutes and 12 seconds:
Dim expectedFormats As String() = {"G", "g", "f", "F"}
myDateTimeUK = DateTime.ParseExact(myDateTimeUKValue, _
expectedFormats, culture, DateTimeStyles.AllowWhiteSpaces)
Console.WriteLine("3) myDateTimeUK = {0}", myDateTimeUK)
Output from this code is:
2) myDateTimeUK = 16 Feb 1992 12:15:12
3) myDateTimeUK = 16 Feb 1992 12:15:12
Output from same code but with myDateTimeUKValue = “ 16 Feb 1992” is:
2) myDateTimeUK = 16 Feb 1992 00:00:00
Code then fails on .ParseExact with ‘FormatException was unhandled; String was not recognized as a valid DateTime’
At least a little progress, if somewhat tortuous – I thought 2005 was supposed to make things easier! I realise that I could of course use the DateTimePicker, but that would break user compatibility with previous production programs.
Kind Regards,
Keith
PS: VB 2005 Beta 1 was fine, no problems.
Hi
I got the same problem on my acer laptop since I reinstalled it two months ago using DateTime.Parse in C# (VS2005). According to the Stack Trace this error is generated in the mscorlib.dll.
The weird thing is that in the VS2003 installation on my machine it works fine. Before I reinstalled my PC it used to work fine for VS2005.
Any help on this matter would be great.
Regards
Wagner Traut
Hi Wagner,
My problem was caused by customising the system's Short Date Format to non-standard (ie. not corresponding to the default regional setting).
You're right, it doesn't cause a problem in VS 2003, nor VS 2005 Beta 1, but with VS 2005 Beta 2 and RTM, it's a real pain in the neck.
I posted a work-around on this thread on Dec 08 2005.
Let me know if I can help further!
Keith Bromley
Hi Keith
Thanks for your reply.
My problem is that the code is using the simple DateTime.Parse which works on all our developer machines and our client's server. So I need to fix it on my laptop preferably without reformatting it...
I am running VS 2005 professional - not the beta 2 version.
I changed my regional settings to be identical to another pc on witch datetime.parse works, reinstalled the framework 2.0 and it's still giving the same error.
Regards
Wagner Traut
Hi Wagner,
I also am now running VS 2005 Pro, the problem remains the same as in Beta 2.
I was only able to reproduce the fault reliably (which occurs in CDate, CType, DateTime.Parse and DateTime.ParseExact), by switching between the default Short Date Format for my Locale and my preferred Short Date Format of dd MMM yy. The fault disappears when using the default date format, and re-appears on changing this.
Further, I only discovered this connection after a clean install on a reformatted drive (you could use a Virtual PC console if you have the software).
For other work-arounds, see the replies to this thread by the Microsoft team.
If the above trials don't reproduce the fault for you, I'm sorry but I have no more suggestions. Also, I'm not that familiar with C# yet, which I think is your preferred language.
Regards,
Keith
I have just updated VS6 to VS2005 and am using VB on XP SP2.
I also use the short date format "d MMM yyyy" and experience the same issue.
Playing around with the Short Date format leads me to believe its the 'space' short date separator that causes the problem.
When you set the Short Date format to the above and apply, the date separator gets set to the space.
Selecting any of the suggested separators puts them back into your date format and the bug goes away eg "d.MMM.yyyy". Not that that helps if you want your choice of short date!
I guess I am going to put a DatePicker on the form ...
Andru
Hi Andru!
It's good to understand a little more of what causes these errors!
Unfortunately I have legacy programs that use the Short Date format with spaces (dd MMM yyyy), and to convert all these is not an option.
I did resolve my problem (see my post of Dec 8th 2005), although using the fix of a French format that I reported may cause other problems down the line, particularly if Microsoft decide to 'correct' this obscure fix!
Thanks for the 'space' info.
Keith
