RSS Feed 7 Posts and 12 Comments till now

Archive for September 6th, 2007

comctl32v6 + MBCS + CEdit::SetFont = 6 hours of pain

Today I was doing some research for an upcoming update to AutoPlay Media Studio. It is an MFC product developed in Visual C++ 6.0 and is compiled with _MBCS (not _UNICODE). The product has user-configurable fonts for many elements such as edit fields.

So, the problem is the if someone chooses a non-Western character set such as Arabic for a font, it will not show characters in the extended character set (codepage) properly in the edit field at runtime or design-time. So, for example, if I type Alt+0199 it should show a funky-cool Arabic character. But instead it shows the 199 character from the standard ASCII character set (Western).

The long and the short of it is that my solution was to take the user’s font settings, create a CFont from them (including the character set) and then set the font into the CEdit control. Here is a clip from a test I did.

m_fnt.CreateFont(-11,0,0,0,0,0,0,0,ARABIC_CHARSET,OUT_DEFAULT_PRECIS,
  CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY,DEFAULT_PITCH,_T("Arial"));
c_EditField.SetFont(&m_fnt);

In the above code, m_fnt is a CFont member variable of the dialog and c_EditField is a CEdit field member of the dialog class. I know this should work because if I make a font like the above, apply it to a device context and then do some text out, the arabic characters will show up properly.

So what is happening??? Well, after much Googling and MSDN reading everything seemed to indicate that I was doing things right. Well at this point I start trying to isolate the problem in a smaller, more controlled situation. I made a new MFC dialog app using the project wizard. I used all of the same project settings that the larger product has. And what do you know, it worked!

So, what was different between this sample app and the big app? Well, for one, the sample dialog app looked old-school (not XP-themed) so I went and added the famous XML manifest that declares a dependency on comctl32.dll v6.0.0.0. And preto-breako - no more Arabic characters.

Long story short, I tried and tried to fix it. Tried setlocale, _setmbcp, SetThreadLocale, etc. Nothing works. From my understanding none of this would be a problem if I was truly on an Arabic version of Windows XP, but it should work - and that is what bugs me. I searched and searched for anything related to this specific problem but could not find anything. So our options are:

  1. Drop the XP theming
  2. Convert the product to Unicode.

1 is not an option because, well, XP theming is sexy. 2 is not an option due to the time constraints of the project at this point and for other technical reasons. So for now I will go with option 3 - do nothing.

If you can help me solve this, I will be eternally grateful.

The Start

OK, I am blogging for real. I have wanted to make a tech blog for sometime now and was recently inspired by fellow Indigo Roser Mark Mruss to get going. Mark started the learning python blog and has had a lot of traffic.

I work for Indigo Rose Software during the day (and sometimes at night) as Director of Product Development. My other Web presence is Icy North Technologies where I have some shareware and articles put together over the years.

So, why the blog then? Well I think that at this point I can add more value to the world and my life by starting to give back some of what I have learned and am learning. I enjoy programming, learning, business and writing, so here I go…