CMonthCalCtrl and localization

CMonthCalCtrl and localization
==============================
Visual C++ 6.0 offers a few new classes. Among these, CDateTimeCtrl and CMonthCalCtrl introduce two new controls: the Date and Time Picker (DTP) control and the Month Calendar control. Since both look very cool I plan to use them in my project. The project I work on is supposed to be deployed in Greece. The good side of both above-mentioned controls is that they can be localized: switch the locale and both controls will display the days and the months in Greek – cool! But because nothing is perfect, there is a down side too. I planed to create my user interface so that it can be switched back and forth between Greek and English at run-time.
As it is explained in the documentation, “the Month Calendar control gets its format and all strings from LOCALE_USER_DEFAULT” (“Month Calendar Control” – MSDN 6.0 – Oct. 99). The LOCALE_USER_DEFAULT, which identifies the locale of the current user, cannot be changed programmatically and keeps all the settings, as they are when the application starts.
Apparently not “all strings” are taken from LOCALE_USER_DEFAULT. I tried to switch from Greek to English and redisplay my Month Calendar control. The result was very strange: the upper part of my control, the one that displays the name of the current month and all the days of week, stayed displayed in Greek. My control was created without the MCS_NOTODAY style applied so that at the bottom it displays today’s date. When I switched to English, today’s date was printed in English: the message was “Today: 21/2/2000”.
Is there a way I can switch ALL the strings for a Month Calendar control back and forth between Greek and English at run-time?
Cheers,
Eddie
LVL 1
MensanaAsked:
Who is Participating?
 
mikeblasCommented:
> Is there a way I can switch ALL the strings for a Month Calendar
 > control back and forth between Greek and English at run-time?

I don't think so.

The control works by looking at the thread locale as it initializes. It finds all the correct names, dates, and parameters from the operating system and caches them. The locale settings the control uses aren't exposed to the client of the control; nor is the locale itself.

I suppose, on Windows NT, you could try using SetThreadLocale() before creating the control to trick it into using a different locale. And then setting it back. You could create two controls, one with Greek and the other with English.

But that seems hacky, and I'm not completely positive it would work as you would expect. And it still leaves you without a solution for Win9x.

Seems like you're going to need to write your own control, or find a 3rd party control that lets you switch around locales.

BTW, why would you need to do this?

..B ekiM
0
 
MensanaAuthor Commented:
>I don't think so.

Somehow I expected this answer.

>The control works by looking at the
>thread locale as it initializes.

If the control would work like this my problem would have been solved from the beginning. Unfortunately, the control takes all its strings from the user default locale and that cannot be changed within an application once it’s started. That’s way using SetThreadLocale will make no difference. And the idea of making two different controls (one for Greek and one for English) won’t work either. Both controls will have the same settings according to what the user default locale was when the application started. What made me to believe it might be a workaround was that the display of today’s date at the bottom side switched between the two languages! Weird, isn’t it?
This might be a bug as I’m not quite sure that this behavior is by design. I mean, why not have a control that gets its format all strings according to the thread’s locale instead of user’s default locale?

>I suppose, on Windows NT, you could >try using SetThreadLocale() before >creating the control to trick it into >using a different locale. And then >setting it back. You could create two >controls, one with Greek and the other >with English.

See above...

>BTW, why would you need to do this?

Well, it’s not a requirement, but we wanted to be able to switch our screens back and forth between Greek and English at run-time all the time. Once the project is on place and an error occurs, you want to be able to understand what’s saying (one can never be sure that his code is 100% bug free!). We already implemented the mechanism that allows us to switch the languages. We just wanted to be consistent with all our screens, including those that have CMonthCalCtrl controls incorporated.

>..B ekiM

I think only a Microsoft insider (like you, Mike, though it might not be your area) can tell me if is there any hope in having a control just like I want it to be. I won’t rate your answer for the time being, but if I don’t get any solution in a few days, the points will be yours.
Thanx,
Eddie
0
 
mikeblasCommented:
> Unfortunately, the control takes all its strings from the user default locale

Yeah, it does. I misremembered the code. It uses the user default.

 > can tell me if is there any hope in having a control just like I want it to be

Doesn't look like it. The control can reload its state; but you'd have to then reset the control panel settings to change locales.

..B ekiM
0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
MensanaAuthor Commented:
I still think that there is a bug in the implementation code for the CMonthCalCtrl (I don’t know, maybe someone should report these to the guys at MS). Maybe in the next patches/releases this will be fixed so that the control will take all the strings from the current thread’s locale as opposed to the user’s default locale. This is the consistent behavior that allows you to switch the language at run-time just like a regular CString object does (via LoadString member).
As I promised, I’ll accept your answer but I’m very upset on all the MS guys :-).
Regards,
Eddie
0
 
mikeblasCommented:
> maybe someone should report these to the guys at MS

I asked around about it, and the code is BY DESIGN to compensate for shortcomings in the localization capabilities of some middle-eastern versions of Windows.

..B ekiM
0
 
MensanaAuthor Commented:
Well, I see this as a restriction. I don’t know how a restriction can compensate some “shortcomings in the localization capabilities of some middle-eastern versions of Windows”.
Eddie
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.