I have a four textboxs, the first one sums a column from a gridview and the 2nd box should multiplies the first box by the last box, the third box should add box two and one. This works on my local pc yet on the server it gives me the error input is not in the correct format. Any help is welcome.
textbox24 = 1.14
textbox 21 = 5234
textbox 22= multiply box24 * box21
textbox 23 = box21 + box22
English - South Africa - both server and local pc
You are using ConvertToDouble before show the text in the textBox22
Your commented line is good, the one below the comment, no ;)
public void Multiply()
{
try
{
double vat = Convert.ToDouble(TextBox24.Text);
double tot = Convert.ToDouble(TextBox21.Text);
double ans = tot * vat;
//TextBox22.Text = ans.ToString().Trim();
TextBox22.Text = ans.ToString().Trim();
}
catch (Exception e)
{
TextBox22.Text = e.Message;
}
}
Marcus and Scott are right. This should be a culture difference between your local pc and your server. You can check them from Regional and Language Options part.
Convert.ToDouble method uses current thread culture.
From documentation;
Using the ToDouble(String) method is equivalent to passing value to
the Double.Parse(String) method. value is interpreted by using the
formatting conventions of the current thread culture.
That means if your textboxes have NumberDecimalSeparator or NumberGroupSeparator for your decimal values, and these properties are not equal for local pc's culture and your server culture, it is too normal to get FormatException.
But since you never mentioned about your textbox values, your local culture and your server culture, we never know what exact problem is.
They said, I can change the settings from the web.config file, does
anyone know how to do this ?
Read How to: Set the Culture and UI Culture for ASP.NET Web Page Globalization
Related
So as I've stated in my question I recently wrote a small program to calculate the amount of bricks needed to build a room, using the following
float result = ((fLenght * fWitdh) * fHeight) * bricksPerMeter;
When Running a test case on both my main computer and a second computer they come up with a different answer
Ex: PC 1 ((15 * 1)* 1.8)* 40 = 1080
PC 2 with the same values produces 600 as the answer
now the error is fixed by changing the decimal symbol on the second computer
I want to know if there is anyway for my code to check if this is the case and attempt to fix it
without me going to each computer and setting it manually
Normally when you launch a .NET application, it takes its default culture settings from the operating system. That is to say that computer configured for German (Germany) would result in the de-de culture being used in the application, and a computer configured for English (United Kingdom) would result in the en-gb culture being used in the application.
With these cultures come things like date format strings, decimal separators, etc. which is where your issue comes from.
A simple solution is to change your code, which is currently:
float.TryParse(value, out fValue) ? fValue : 1f
to use the Invariant Culture:
float.TryParse(value, NumberStyles.Any, CultureInfo.InvariantCulture, out fValue) ? fValue : 1f;
This will then use the invariant culture, whose decimal separator is ., to parse the string to a float.
Note that you'll probably want to enforce a culture when you convert the result back to a string. One way to do this is by passing a culture to the .ToString method:
string resultText = result.ToString(CultureInfo.InvariantCulture);
Console.WriteLine(resultText);
Alternative solution (but not recommended): you could override the default culture for your entire application but that might cause problems for you elsewhere, so I don't recommend this.
VS:2005, framework: 2.0
I have a dropdown with French and English languages. As User selects a language, We set CultureInfo as fr-FR or en-US respectively.
When retrieving float values from DB we assign value as
Convert.ToDecimal(table.Rows[0]["diametre"].ToString(), System.Globalization.CultureInfo.InvariantCulture)
In french, 1.3 is displayed as 13 or sometime gives "input string was not in a correct format." error. I tried follwing code:
System.Globalization.NumberFormatInfo numberFormatInfo = new System.Globalization.NumberFormatInfo();
if (System.Globalization.CultureInfo.CurrentCulture.Name == "fr-FR")
numberFormatInfo.NumberDecimalSeparator = ",";
else
numberFormatInfo.NumberDecimalSeparator = ".";
Convert.ToDecimal(table.Rows[0]["densite"].ToString(), numberFormatInfo)
But gives Input String error as above. When "en-US" culture, it works perfectly fine!
What else should I try?
This is giving quite a pain now. Please help me.
TIA
Update:
Thanks all, for responses!
I had help from a colleague while fixing bug. We did following change:
decimal diametre = Convert.ToDecimal(table.Rows[0]["diametre"].ToString().Replace(",", "."), new System.Globalization.CultureInfo("en-US"));
Thanks Tim for useful info like "ToString will use the current culture's decimal separator"
Why is diametre a string at all? If it's a decimal in the database you should use:
decimal diametre = table.Rows[0].Field<decimal>("diametre");
That will be more efficient and also prevents localization issues.
Otherwise you can use decimal.Parse with the appropriate culture-info:
var french = new CultureInfo("fr-FR");
decimal diametre = decimal.Parse(table.Rows[0].Field<string>("diametre"), french);
Update i've only just seen that you're using .NET2, then the Field-extension method is not available. You have to cast it to the correct type, i still wouldn't use ToString to convert everything to string since that could modify it(f.e. if it's a decimal, ToString will use the current culture's decimal separator).
decimal diametre = (decimal)table.Rows[0]["diametre"];
or
decimal diametre = decimal.Parse((string)table.Rows[0]["diametre"], french);
If it's always stored with the dot as decimal separator as in en-US for example, you can use:
decimal diametre = decimal.Parse((string)table.Rows[0]["diametre"], CultureInfo.InvariantCulture);
If you then want to diplay it with the correct format use decimal.ToString:
string output = diametre.ToString(french);
Basiclly, you have 2 cultures in .NET.
You have a culture and you have a UI culture.
The Culture affects how culture-dependent data (dates, currencies, numbers and other information) is being displayed to the user.
The UI culture affects the resource file to be used, so first of all, if you just want to change the language, but keeping the date formates and other information like configured on the computer, you should only change the UI culture and not the culture.
However, the answers given above are valid.
If the field is a number, store it as a number and not a string.
Use Parse with the correct culture.
#Tim I gave you credits for your answer, but I wanted to contribute with this aswell.
I know this question is old, but it might help others who have the same issue and none the above solutions has helped them. For me, adding this line of code to the MainPage constructor of my app (I'm using xamarin.Forms), solved the issue.
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB");
Hope it helps, it simply sets the culture of the application to english, regardless of what the devices culture/language has been set to, so if you need the app to behave locally, then this might not be a good solution
You can convert your dbValue first like this:
string MyValue = (String)(table.Rows[0]["diametre"] == DBNull.Value ? string.Empty : table.Rows[0]["diametre"].ToString);
then replace possible comma by dot:
if(!string.isNullOrEmpty(MyValue)){
MyValue.Replace(",",".");
}
and then Convert it to decimal:
Convert.ToDecimal(MyValue, System.Globalization.CultureInfo.InvariantCulture)
My website extracts data from a text-file into a database. After reading the data, I convert string-values into double, using:
oracom.Parameters.Add("nstpreisvm", OracleDbType.Double).Value = Convert.ToDouble(_material.Mat_StPreisVm);
If I check the results in the database now, (The column expects the NUMBER-format), I get two different values: On my localhost via Visual Studio 2010, the database returns 10,15 - But if I make the process on the webserver, the database only shows 10. How does this happen?
I implemented a little lable on the website now, filling it with the current culture on the Page-Load:
label.Text = Thread.CurrentThread.CurrentCulture.ToString();
The CurrentCulture is en-GB for both instances, so what is the problem here? Am I missing anything?
My local windows is Win7 SP1 with a german language-pack, the server is Win2008 R2 with standard English installation.
We had a similar problem on a customer server where the customer had manually changed the decimal separator symbol for a particular culture on that server. You can check this using:
Thread.CurrentThread.CurrentCulture.NumberFormat.NumberDecimalSeparator
I would suggest explicitly specifying the decimal separator symbol when you do the parsing:
Double.Parse("1,25", new NumberFormatInfo(){ NumberDecimalSeparator = "," });
I have written a small program where the program works differently on different operating systems (xp, win7) The problem is the program reads some float numbers such 2,686.
One operating system (win7) convert it to float true, but on xp it goes wrong and print it 2686. How can I understand which symbol the operation system uses for decimal numbers ?
Thanks.
string sep = CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator;
This does not depend on the operating system but at the (default) language settings on each PC.
If you use : double value = double.Parse(text); you are using whatever culture the user has configured. If you know the input to be in a certain format, use:
var ci = CultureInfo.GetCulture("nl-NL"); // dutch
double value = double.Parse(text, ci);
Every function that converts has (1 or more) overloads to take a FormattingProvider (Culture).
parse the floating point numbers using the user current culture with double.Parse(string, System.Globalization.CultureInfo.CurrentCulture);
The decimal separator is decided by the current culture.
If you want to use a specific character as decimal separator, you can create a custom NumberFormatInfo object with any separator you like. If you want to use period as deimcal separator, you can simply use InvariantCulture:
double n = Double.Parse(s, CultureInfo.InvariantCulture);
If you want to use comma, you can choose a culture that has that, for example swedish:
double n = Double.Parse(s, CultureInfo.GetCultureInfo("sv-SE"));
I have a textbox accepting user input; I am trying to use this user input it to populate this member of one of my business objects:
public System.Decimal? ExchangeRate
The application is localized - I need to support at the same time cultures that accept these as valid inputs: "1,5" and "1.5"
The code I have now is:
var culture = Thread.CurrentThread.CurrentUICulture;
int exchangeRate;
int.TryParse(txtExchangeRate.Text, NumberStyles.Number, culture,
out exchangeRate);
entity.ExchangeRate = exchangeRate;
When the user culture is set to a culture that expects the "1,5" format (comma as decimal separator) - e.g "ro-RO", I want the value that gets stored in entity.ExchangeRate to be 1.5; however, when running the code above, it gets converted to 15 instead.
Any suggestions on how to convert these various formats so that the data that gets stored in my business entity is "1.5" (point as decimal separator)?
Thanks.
You guys were right - it made sense to use Thread.CurrentThread.CurrentCulture instead of Thread.CurrentThread.CurrentUICulture and decimal.TryParse instead of int.TryParse.
But these changes would still not solve my problem. And after playing around with the code some more, I can now simplify the issue to this:
I am using a telerik RadNumericTextBox control which enforce users to use the correct format based on their culture. So, when Thread.CurrentThread.CurrentCulture is set to "ro-RO", it will only accept the "1,5" format, and when it's set to "en-GB", it will only accept the "1.5" format.
Here's the code I am using now:
decimal exchangeRate;
decimal.TryParse(txtExchangeRate.Text, out exchangeRate);
entity.ExchangeRate = exchangeRate;
Case 1: current culture is "en-GB" - accepted input is "1.5" , exchangeRate is set to 1.5 - everything works fine.
Case 2: current culture is "ro-RO" - accepted input is "1,5" , but after executing the decimal.TryParse... line, exchangeRate is set to 15 - wrong, obviously.
I should also mention that in this case, the value of txtExchangeRate.Text is also shown as "1.5" in my Watch window.
So, it looks like decimal.TryParse will take into consideration the current culture, but I can't find a way to actually make it work properly for me. Any suggestions?
OK, here's the code that seems to work on both cases I described in my above post (1. culture "ro-RO", comma as decimal separator and 2. culture "en-GB", dot as decimal separator):
decimal exchangeRate;
decimal.TryParse(txtExchangeRate.Text, NumberStyles.Any,
CultureInfo.InvariantCulture, out exchangeRate);
entity.ExchangeRate = exchangeRate;
Obviously, int cannot hold 1.5 ! :-) Use float instead.
Use CurrentCulture instead of CurrentUICulture. My culture is fr-BE (therefore accepts 1,5 but my Windows UI is English, which doesn't).
I would make the float.Parse() test with both CurrentCulture AND InvariantCulture: By the time some programs learned to accept "1,5", everybody was used to type "1.5". There's nothing which bothers me more than Excel requiring me to type 1,5 when I say 1.5 ! Also, here in Belgium, the 1st year government launched the web-based tax declaration, the site forced you to use commas instead of periods as decimal points. Everybody was wondering why the figures entered were refused!
So be nice to your users and accept both.
FYI I know this isn't your problem, but its a pointer for other people who might be doing this:
When you set your culture, you can't have your application be able to handle input of different cultures. It must be of the type that you have specified.
Therefore, if you set ro-RO as the culture, it won't understand both 1.5 and 1,5 as the same thing.
You should probably be using CurrentCulture (as opposed to CurrentUICulture) for localization (e.g. date/number formatting).