Why i can't localizing datetimepicker control?

  • Thread starter Thread starter Sarawut
  • Start date Start date
S

Sarawut

I use windows 2000 and set regional option as "thai". I
use datetimepicker control in my .net application. And I
chang Culture of my Application to "en-US" by use code
below

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-
US");
Thread.CurrentThread.CurrentUICulture = new CultureInfo
("en-US");

But my datetimepicker still display in thai language.
How can i display it in English language.
Thank You.
 
The DateTimePicker is hardcoded to use the language
that the user has specified in his/her regional settings.
You can't change it locally in your app.

/claes
 
The DateTimePicker is hardcoded to use the language
that the user has specified in his/her regional settings.
You can't change it locally in your app.

Pretty stupid, really...... thank goodness there are other component
sets out there which are a bit less brain-dead in their design! :-)

Marc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
Marc Scheuner said:
Pretty stupid, really...... thank goodness there are other component
sets out there which are a bit less brain-dead in their design! :-)

Well, this is a bit harsh.

The original control is a WINDOWS common control that is design to work the
Windows and respect the user's settings. Clearly when your application runs
those settings cannot comletely suck, since they are the settings that the
user has chosen, and developers who think their users suck have bigger
problems...

VS wanted to be able to use these common UI elements in .NET. Which is fine
too, people like using common UI elements -- consistency is good.

The only time there is problem is when an application tries to both (a) use
the common UI elements, and (b) use a different language than Windows is.
This is not a terribly common scenario and I can understand why the team
that owns those UI elements would be loathe to go out of their way to
support a scenario not required by the platform.
 
Marc,

It looks like you did not understand my response. Nothing I said is
US-specific or deals with mono-lingual countries (I see your Switerland and
raise you one India! <grin>).

What I am saying is that if you understand that the control is actually
provided by the platform and not by the .NET framework, its easy to see both
why the limitation exists and why they are unlikely to fix it in the
platform (especially downlevel).

Now perhaps if the scenario were communicated loudly enough to framework
people, they could give up on the common UI element control as provided by
the OS and make their own -- supporting whatever they wante. Though I am
sure you can imagine how big of a task *that* would be. :-)


--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.
 
Well, in that case, I would have to respond that the decision to use
such a "locked-in" non-internationalizable component for .NET was a
big boo-boo in my opinion. Heck, if you go to such great lengths to
support your international customers, can't you rewrite a little thing
like a DatePicker control, too? Seems like a huge amount of work has
been done, but corners have been cut in places where they shouldn't
have been..........

Sounds like there are a few misunderstandings here

The DataTimePicker has very good support for international settings.
What it lacks is a way to set its language independent of the user's
preferences, which is what the OP wanted. And this is not
necesarily a bad thing!

If you're running an english (US) version of Windows and your
regional settings are set to swedish (which is how I am running
things btw) the datetimepicker display dates according to swedish
rules, just as you would expect it to do.

But if your application internally changes it's culture to something
else it will ignore that. I can't find any reason (other than debugging)
why your application should use another language than the one the
user is comfortable with and thus has selected in his/her regional settings.

The original language of the OS has nothing to do with this

/claes
 
But if your application internally changes it's culture to something
else it will ignore that. I can't find any reason (other than debugging)
why your application should use another language than the one the
user is comfortable with and thus has selected in his/her regional settings.

Again - if I run a system which is set up with a German OS, and where
the language preference is set to German, but two people share that
machine and one of them is French speaking - I think there should be a
way for an app to switch to a different culture (and all of its
controls should switch, too) so that the user in question can work in
his/her preferred language.

If you live in a (predominantly) mono-language country like the US or
Sweden, you might not see that need - but Switzerland is a
four-language country, not to mention others like India or China with
literally hundreds of languages. Why can't I make it so that a person
can walk up to a PC, launch an app, and say "Hey, I'd like to have
everything in French / Italian / (your favourite language)" and then
the app and the .NET framework will actually SUPPORT that, without
having to fiddle with system settings such as regional preferences
etc.????

MArc

================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
Back
Top