Link to home
Start Free TrialLog in
Avatar of jadixon
jadixon

asked on

CDateTimeCtrl and Cyrillic (Russian)

I have an application that uses the CDateTime Ctrl with up/down arrows. It also contains several "fields" of data (DDMMYYYY HHMMSS). One of these is also a text string indicating GMT or Local time. These can be displayed in several different languages. All the languages except cyrillic (russian) work fine. When in russian, the spin buttons don't work at all. The user can type in the date, but the selection of GMT vs Local (in russian) cannot be chosen.

Is there some sort of wide character include or function call I need to use instead of the "normal" one?
Avatar of pgnatyuk
pgnatyuk
Flag of Israel image

No. Just check that you have Russian language support installed.
Everything in Windows is Unicode. So there is nothing to convert. I think, the control simply cannot retrieve this data in Russian. Maybe, you made something complicated with the format or something wrong in the notification handlers?

If you want you make create a new MFC dialog-based project and set the Russian in the dialog resources, put on the dialog only this control and check.
Avatar of jadixon
jadixon

ASKER

I disagree that "everything in windows is unicode". I have had to make lots of adjustments for unicode, using wchar type calls instead of just char calls (for example). And the text appears ok, I just don't understand why the spin buttons do not work even for numbers (like the hours and minutes).
:)

Instead of everything you did, you could just set Unicode character set in projects. If you work with the text files, make them in Unicode.

Unicode is a "native" Windows format. Period.

But it is another story.

Check your control in  a new MFC dialog-based application that will use Unicode character set and set up Russian languages for this app. We'll see what's going wrong.
Basically what pgnatyuk is saying is under Project Properties/General, set the character set to Unicode.  Your project may be defaulting to either "Not Set" or "Use Multi-byte character set".

It took me ages to figure out this one, the first time it happened to me.
Avatar of jadixon

ASKER

I am working with an existing project that is in Visual C++ 6.0. As far as I can tell, there is no "Character Set" setting. However, under the preprocessor it does link in some unicode libraries and uses a unicode parameter in the project options.
Check under Settings-> C/C++->General.  By default _MBCS is defined.  Remove this and replace it with UNICODE (note, no leading underscore).
Also, are you using TCHARs or wchar_t?
There is a legal way to set Unicode in Visual Studio 6.0. It is in the project settings. I'm not sure that this is on the first page but it should be the same: "Use Unicode Character Set"/"Use Multibyte Character set".

I do not think that it will solve the question.

I'd check the Russian language installation on the computer. Also if the default language is not Russian, the Time Zone information can be in English (or whatever is default) too. So anyway you may see this data not Russian. So I think you will see this info in Russian only on the Russian computer.

If you want to see it on other computers... I may need to to develop/modify this control.
Avatar of jadixon

ASKER

I have a system that I have Russian XP loaded on. On that system, the spin buttons on the date field do not work at all.  The user can change the data by typing it and it saves the data. I have another system that is English XP, but the user can change the language for displaying the data. When the user is in any non-unicode language, the spin buttons and date control work fine. When the user is displaying the data in Russian, the spin buttons do not work and the date data disappears when the user moves off the field, like it unchecks itself.

I am assuming that this is due to the control not supporting unicode. I have tried setting the unicode status of the control with SendMessage statements and MonthCal_SetUnicodeFormat, but that has not helped.
Have you checked that ICC_UPDOWN_CLASS and ICC_UPDOWN_CLASS are in the InitCommonControls initialization?  If they aren't, it will build but those controls will not work.

Also track through to the SendMessage.  Is it calling SendMessageA or SendMessageW?
Avatar of jadixon

ASKER

I don't explicitly see ICC_UPDOWN_CLASS, but it works fine on the regular English system, so I would assume they are working.

As far as the SendMessage, I was using just SendMessage, no A or W.  Would that make a difference?
Avatar of jadixon

ASKER

The other thing that puzzles me is that when in Russian it acts like the checkbox for the control does not get checked (even though I can see it get checked). When you move off the field, the entry disappears. The date control part works fine, it is just the time one. We do have a custom format on that control, which I did find something on the internet that someone else had a problem. But it is confusing that it works fine in english (and other non-unicode languages) but not with Russian.
Anything will work in English because all the characters are less then 127.  When you go to other languages,  you have a choice of MBCS, DBCS or Unicode.  It really depends on the language's encoding system.

One thing I haven't asked is whether the Russian text is coming out correctly.

Both English and Russian can be either MBCS or UNICODE.  Do you have UNICODE defined?  Are you using TCHARs or just chars.  If it is UNICODE, then you really ought to be using TCHARs.  It might be that either the UNICODE or the MBCS codes are wiping out the selection

SendMessage is a macro - it is defined as either SendMessageA if UNICODE is not defined or SendMessageW if UNICODE is defined.

On the both systems, do you know which libraries you're linking to?  Is it msvcrt or msvcrtu, msvcp60 or msvcp60u.  The Unicode systems link to the ones with a U suffix.

How about just creating a simple dialog with just an check box and a button.   Define UNICODE in C++/preprocessor.  Check if it exhibits the same behaviour.
ASKER CERTIFIED SOLUTION
Avatar of jadixon
jadixon

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
What type is m_sstrConfigLOCAL?

It depends on what the control wants.  If m_sstrConfigLOCAL is a char* and you are working in Unicode, CStrings will store chars as TCHARs and it has a LPCTSTR operator, which will convert it to the appropriate type.
Avatar of jadixon

ASKER

m_sstrConfigLOCAL is a CString, which is why I am a bit confused as to why I needed to re-typecast it. But it is now working fine, so  I am ok with that.
Just curious, which routine is it that needs the typecast?