CODEWITHSUNDEEP
c++windowsunicodemfc
stephen
stephen

Reputation: 323

Unicode Support in MFC Controls

I'm exploring converting an existing MFC app from MBCS to Unicode, and I'm compiling a simple starter app in Unicode mode to check out how edit controls, for example, behave differently in Unicode/W or MBCS/A mode.

But I'm getting some strange results.

If I enter Alt+1702 into Word, for example, I get the Arabic character (ڦ) which is expected from the Unicode table.

But if I enter Alt+1702 into an edit control in the Unicode MFC app, I get a superscript "a" (ª) instead. This is the same behaviour that I get from the existing MBCS app.

This second behaviour also happens in Word (2007) if I use File-Open and enter Alt+1702 in the Filename field. But it comes through properly if I enter it in the Font combo in the Ribbon.

What am I missing here?

Upvotes: 1

Views: 518

Answers (1)

phuclv
phuclv

Reputation: 41753

Windows disables hex-numpad by default. You must enable it and enter the value using Alt++Hex value

How to enable it:

About the reason why Alt+1702 produces ª

Alt codes are generally limited to ANSI or OEM code pages only and won't work for code points larger than 255. A few apps (like MS Word as you experienced) do support larger values, which means Alt+1702 will produce U+06A6 (Arabic letter peheh = ڦ) as expected (1702 = 0x06A6). Some other apps just throw away any digits after the third one. But by default in almost all applications if you input any larger values then only the low byte of the real value is taken as the code point, i.e. modulo 256

So pressing Alt+1702 will be equivalent to Alt+166 because 1702 ≡ 166 (mod 256). When you run US Windows which uses code page 437 for the OEM code page then the character at code point 166 is ª

Upvotes: 1

Related Questions