ThinkGeo.com    |     Documentation    |     Premium Support

FormatException in Datum constructor

#1

Hi,

I am using ThinkGeo version 2.44.5. For compatibility reasons I cannot upgrade to new versions.
My .net application has a configuration of Local Culture Language and on startup I can set language and culture of my application.
In many years that I used your map control I set more times english or italian and all works fine.
In these days I tried to set French or Czech language but I receive an exception directly in new Datum() constructor:

System.FormatException: Input string was not in a correct format.
at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
at System.Convert.ToDouble(String value)
at MapSuiteProjection.Ellipse._799ef4b55a5714f0()
at MapSuiteProjection.Ellipse…ctor()
at MapSuiteProjection.Datum…ctor()

These happens independently of map layers used.

How I can solve my problems?

Thank you very much

#2

Hi Dino,

This version was released 17 years ago, I’m grad it still works but I’m afraid we no longer provide support for it. This issue is due to the fact that French and Czech use a comma as the decimal separator and a period for the thousand separator(so instead of 1,234.56, it is formatted as 1.234,56). This problem was addressed in more recent versions, but we are unable to retroactively fix it in v2.44.5.

You might consider changing the decimal point and thousand separator in your system’s regional settings to align with English formatting, if that change is feasible on your server. Otherwise, I’m afraid there is little we can do. If you want to upgrade it to the latest version, we are happy to help.

Thanks,
Ben

#3

Hi Ben,

thank you very much for your reply.
The strange thing is that usually I use italian language and comma is the decimal separator as for french.
Looking in Windows settings I see that French and Czech seems to have an empty thousand separator, maybe is that the problem.
Can you tell me what is the minimum version where this problem has been solved?

Thanks

#4

Hi Dino,

Regarding the API:
In V3, we completely redesigned all the APIs and have since maintained this architecture up to the current version, which means the time taken to upgrade to v3.0 is similar to that needed for upgrading to the latest version. As a result I recommend upgrading directly to the latest v13.1, please be aware though that all mapping sections will need to be rewritten, as the new APIs are significantly different from those in v2.
v12 web samples: Files · develop · ThinkGeo / Public / Web Maps · GitLab

Regarding the products:
Since your question was posted in the WebForms forum, I assume you are using the v2 Web Edition. The web technology used in V2 has been deprecated, upgrading to the latest version (WebAPI v13 or Blazor V13) will likely require a rewrite of your web project. We do offer a v10 WebForms edition that closely resembles V2’s web edition (though the APIs are entirely different), and upgrading to this version should demand the least effort on your part.
v10 Web samples: Files · support/v10 · ThinkGeo / Public / Web Maps · GitLab

Regarding the .NET Framework:
While Map Suite V2 supports .NET Framework 2.0, V13.1 has compatibility with .NET Framework 4.6.2+, .NET Core 3.1+, and .NET 5+. V10 supports .NET Framework 4.5+. One thing needs to be aware is Microsoft has stopped supporting the old .NET frameworks. Microsoft .NET Framework - Microsoft Lifecycle | Microsoft Learn

Upgrading a 17-year-old project will undoubtedly require substantial work. If you aim to ensure future maintainability of your project, I recommend taking the plunge and upgrading to the latest version — something you have to do sooner or later. However, if you are looking for a quick fix just for this issue at this time, maybe a better way is to reach out to support@thinkgeo.com, share your project details with us, and we’ll see if we can assist by treating it as a professional project.

Thanks,
Ben

#5

Thank you very much Ben for your informations.
Since it is in my application that I change Locale settings and Language I apply the following workaround:
if the NumberGroupSeparator (of Thread.CurrentThread.CurrentCulture.NumberFormat) is char 160 (the Non-breaking space) I set NumberGroupSeparator to ‘.’ if NumberDecimalSeparator is ‘,’ or vice versa.
This patch seems work fine.
If I will find other problems I will think to upgrade to latest version.

Thanks

#6

Sounds good. Just let us know if you need any help.