Setting CultureInfo in Application level

  • Thread starter Thread starter Shiplu
  • Start date Start date
S

Shiplu

Hello,

Is there any way that I can set current cultureinfo for the current
application or current thread?

I have coded lots of classes already. Most of them uses methods those
are culture dependent. Like DateTime.ToString(), Int.Parse() etc.
Now I dont want to write CultureInfo.InvariantCulture parameter for
every method. It'd be great If I could set it for current application
at the very beginning then rest of the application will use the
CultureInfo.InvariantCulture.
Hope you understand.

Thanks In advance.
 
Hello,

Is there any way that I can set current cultureinfo for the current
application or current thread?

I have coded lots of classes already. Most of them uses methods those
are culture dependent. Like DateTime.ToString(), Int.Parse()  etc.
Now I dont want to write CultureInfo.InvariantCulture  parameter for
every method. It'd be great If I could set it for current application
at the very beginning then rest of the application will use the
CultureInfo.InvariantCulture.
Hope you understand.

Thanks In advance.
Click to expand...


Forgot to tell. Its a .NET 2.0 Console Aplication.
 
Hello,

Is there any way that I can set current cultureinfo for the current
application or current thread?
Thread.CurrentThread.CultureInfo.

I have coded lots of classes already. Most of them uses methods those
are culture dependent. Like DateTime.ToString(), Int.Parse()  etc.
Now I dont want to write CultureInfo.InvariantCulture  parameter for
every method. It'd be great If I could set it for current application
at the very beginning then rest of the application will use the
CultureInfo.InvariantCulture.
Hope you understand.
Click to expand...

You should not do that, however, because that way you override user
settings for all cases where you actually output strings. The
recommended way to go about is to explicitly specify
CultureInfo.InvariantCulture. Yes, it's long, but at least it's clear.
 
I have this in my mainform constructor. It then works throughout the
application

// setup the date format application-wide
CultureInfo myCulture = new CultureInfo("en-US");
myCulture.DateTimeFormat.ShortDatePattern = "MM/dd/yyyy";
Application.CurrentCulture = myCulture;



Hello,

Is there any way that I can set current cultureinfo for the current
application or current thread?
Thread.CurrentThread.CultureInfo.

I have coded lots of classes already. Most of them uses methods those
are culture dependent. Like DateTime.ToString(), Int.Parse() etc.
Now I dont want to write CultureInfo.InvariantCulture parameter for
every method. It'd be great If I could set it for current application
at the very beginning then rest of the application will use the
CultureInfo.InvariantCulture.
Hope you understand.
Click to expand...

You should not do that, however, because that way you override user
settings for all cases where you actually output strings. The
recommended way to go about is to explicitly specify
CultureInfo.InvariantCulture. Yes, it's long, but at least it's clear.
 
I have this in my mainform constructor.  It then works throughout the
application

            // setup the date format application-wide
            CultureInfo myCulture = new CultureInfo("en-US");
            myCulture.DateTimeFormat.ShortDatePattern = "MM/dd/yyyy";
            Application.CurrentCulture = myCulture;
Click to expand...

Great; now can you explain me, why should I see those weirdly
formatted U.S. month-first dates when I'm running this on e.g. UK
locale? What about any other region that doesn't use it (which is
pretty much all of them outside of U.S.)?

Those Regional Settings in Control Panel are there for a reason. If
user says that he wants numbers and dates to be formatted so-and-so,
then UI should just do what's it told, not try to circumvent user
choices.
 
You should not do that, however, because that way you override user
settings for all cases where you actually output strings. The
recommended way to go about is to explicitly specify
CultureInfo.InvariantCulture. Yes, it's long, but at least it's clear.
Click to expand...

Well, Actually I am working with some log files. Those log files
follows the specification of the manufacturer. And these log files are
generated by a hardware.
After parsing those log files, I am outputting in another standard
format which has another spec too. That output file will be read by
another hardware.
So there is no user who is going to read it. To make it compatible
with the hardwares the format must be consistent. Thats the reason,
why I needed invariant CultureInfo.

Thanks Mel for your solution. But I am working in a console
application. There is no form. The only entry point is Program
function. I dont see any static Application object too.

I am using the solution of Pavel. Now I dont see any warning on code
analysis. Thanks Pavel.
 
We don't sell our product outside the US and never will. It is an insurance
specific product :)

I have this in my mainform constructor. It then works throughout the
application

// setup the date format application-wide
CultureInfo myCulture = new CultureInfo("en-US");
myCulture.DateTimeFormat.ShortDatePattern = "MM/dd/yyyy";
Application.CurrentCulture = myCulture;
Click to expand...

Great; now can you explain me, why should I see those weirdly
formatted U.S. month-first dates when I'm running this on e.g. UK
locale? What about any other region that doesn't use it (which is
pretty much all of them outside of U.S.)?

Those Regional Settings in Control Panel are there for a reason. If
user says that he wants numbers and dates to be formatted so-and-so,
then UI should just do what's it told, not try to circumvent user
choices.
 
We don't sell our product outside the US and never will.  It is an insurance
specific product :)
Click to expand...

There's no reason why a user in a particular country might not want to
change the date format to something different from the established
convention in that country. Personally, I always set mine to YYYY-MM-
DD on any locale.

An interesting question though - if you only distribute in U.S. (and
assume that everyone is going to have U.S. locale), then why did you
even feel the need to override that setting manually and globally?
 
We wanted the two digit month and day.

We don't sell our product outside the US and never will. It is an
insurance
specific product :)
Click to expand...

There's no reason why a user in a particular country might not want to
change the date format to something different from the established
convention in that country. Personally, I always set mine to YYYY-MM-
DD on any locale.

An interesting question though - if you only distribute in U.S. (and
assume that everyone is going to have U.S. locale), then why did you
even feel the need to override that setting manually and globally?
 
Back
Top