by Michael S. Kaplan, published on 2006/02/01 13:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/02/01/522164.aspx
Mohit Gogia asked me via the contact link (though the suggestion box would have better!):
Hello Michael,
I have posted this internally and on forums but couldn't get any definitive answer to the question. Please help me with the following.
I am having a situation where OS locale is different from Application locale. Now since MessageBox come from OS so they are in OS locale (Yes, no, OK buttons) rather that in the application locale. I am reluctant to make custom messageboxes in resource dlls. MSDN mentions about an MessageBoxIndirect API which is supposed to take a langid parameter and show the MessageBox in user specified language on a MUI m/c (I have installed the MUI pack). But I couldn't make this scenario work with MessageBoxIndirect, messageboxes were still in the OS language rather than in application specified language.
Here is the code tried on a MUI setup with current OS locale English.
MSGBOXPARAMS mBox;
memset((void*)&mBox, 0, sizeof(MSGBOXPARAMS));
mBox.cbSize = sizeof(MSGBOXPARAMS);
mBox.dwLanguageId = 1041;
mBox.dwStyle = MB_YESNO;
mBox.lpszCaption = L"Hello";
mBox.lpszText = L"Hello";::MessageBoxIndirect(&mBox);
-Thanks
I just tried to look for it and could not find it, but it was more than five years ago that I asked this very same question!
I remember Björn Rettig responding to me, and telling me that the work to support this "pre-MUI" mechanism of UI language switching was never actually hooked up.
At the time, I was pretty pissed off. And being a contract resource, in a conversation that was not with anyone in my reporting chain, I think I talked about how lame it was for Microsoft to put in teasers like this, without ever adding the functionality.
But to his credit, Björn (who is one of the original "concept wizards" behind MUI) talked about why it really was not a good idea. And it was hard to get around the fact that I just didn't feel like doing the work.
So I admitted it. :-)
Thinking about it now, and as I pointed out in the post Just when you think you know a function..., trying to handle localization tasks in developer code rather than putting the job in the hands of localizers is really not a very scalable plan. There is a huge difference for the developer between making things localizable and trying to be clever about the localization.
So it is probably all for the best that this parameter does indeed represent the road not travelled.
This post brought to you by "ö" (U+00f6, a.k.a. LATIN SMALL LETTER O WITH DIAERESIS)
referenced by
2006/05/25 SQL Server's cross-version collation support