Currency and site culture

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
8/4/2011 5:42:51 PM
Jamie E
Gravatar
Total Posts 1203
View Posts
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Currency and site culture

Hi guys, I thought I'd take the original currency discussion thread to the developer forum where it belongs.

So using Joe's technique of forcing site culture (en-US) on the displayed amount, the currency symbol is displayed correctly as $, regardless of browser culture. However, I have a separate text box where the user enters the amount they are going to pay (this box defaults with the current amount due, again in site culture format). After my changes, it all looks right. They could have an amount due of $155.67, and that will display as the amount due, and the amount to pay box will default with 155.67. All good so far.

Now, if I have my browser language set to es-ES, or even the generic es, performing the currency conversion on a defaulted or entered amount of "155.67" results in a displayed amount to pay of $15,567.00. I know this is due to the browser culture specifying "," for the decimal separator and "." for the thousands separator. If I set my browser to Spanish U.S. (es-US) or Spanish Mexico (es-MX) it uses "," for thousands and "." for decimal, just like USD, and everything works as expected.

I guess theoretically it's up to the user to be aware of the culture they are using, and adjust entry accordingly, but it seems very confusing because the USD conversion of displayed amounts is showing #.##, although it seems to expect entry in #,## format.

Here is a code snippet so hopefully someone can give me a pointer on what to change.

currencyCulture = ResourceHelper.GetCurrencyCulture(siteSettings.GetCurrency().Code);

lblAVAmtDueVal.Text = acct.AcctBase.CurrentAmt.ToString("C", currencyCulture);

suggAmtToPay = acct.AcctBase.CurrentAmt - pendingPymts;
if (suggAmtToPay <= 0)
{
   suggAmtToPay = 0;
   lblAVAmtToPayWarn.Visible = true;
}
tbAVAmtToPay.Text = suggAmtToPay.ToString("F", currencyCulture);

// Validation of entered tbAVAmtToPay.Text here
  
lblCIAmtToPayDispVal.Text = decimal.Round(decimal.Parse(tbAVAmtToPay.Text), 2).ToString("C", currencyCulture);

Has anyone else faced a situation like this? Boy, I sure feel fortunate that I haven't had to struggle with this all along. Globalization is tough!

Thanks,
Jamie

8/5/2011 6:42:06 AM
Joe Audette
Gravatar
Total Posts 18439
View Posts

Re: Currency and site culture

Hi Jamie,

The key is that you must also use the currencyCulture when parsing a string into decimal. This is a good example that illustrates the benefit of the mojoPortal source code for learning. What I would like developers to think of is "hey the WebStore feature must handle user input for setting the price I wonder how it works there", and then they would look around in the WebStore source code and see how it is done in the AdminOfferEdit.aspx.cs file like this:

offer.Price = decimal.Parse(txtPrice.Text, NumberStyles.Currency, currencyCulture);

So the concept is that both when formatting numbers/dates as string and when parsing strings back to numbers or dates there are method signatures that take IFormatProvider and you use that both for formatting and parsing. If you don't pass it in it just defaults to using the current culture of the executing thread. In your example that is what causes it to parse it incorrectly because its parsing with es-ES unless you pass in a specific CultureInfo to use. Note that it doesn't always cause an error because it is still numeric data in the string, in this case it just causes a mistake.

I think many things in the .NET framework are designed well enough that its easy to stumble upon what you're looking for, but these particular method overloads are easier to stumble over than upon them. If the method signature said it takes a CultureInfo object then I think it would be more discoverable and people would stumble upon it, but since it takes an IFormatProvider its easy to stumble over it not knowing what can be provided there, but once you know that a CultureInfo object implements the interface IFormatProvider then you realize that you can pass it in anywhere that expects an IFormatProvider.

Hope that helps,

Joe

8/5/2011 6:07:46 PM
Jamie E
Gravatar
Total Posts 1203
View Posts
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Currency and site culture

Thanks as always for your infinite patience, Joe! yes

You must sign in to post in the forums. This thread is closed to new posts.