Re: How to write a program with multi-language support but not needed to define "UNICOE"?

On Sep 23, 5:07 am, Black Smith wrote:
Hi,

I have do a little search and it ssems that if you want to write a multi-language support program but not want to define "UNICODE", you need:

1. Put each resource file with different langauge in different dll. But I haven't done this before. Is there any sample code teaches how to build resource file into a dll and how to use the dll type rescource file in program?

Even if you do use Unicode, that's still the method of choice. .NET
uses that; native Delphi (I know, irrelevant) uses that. MFC
applications should use that approach, too. About building resource-
only DLLs: see http://msdn.microsoft.com/en-us/library/24b2tcy0(VS.80).aspx..
About the sample code: for recent MFC versions, there should not be
any, InitInstance does it all, or almost^^^ (look appcore.cpp,
AfxLoadLangResourceDLL and friends).

So for example, you build your english resources into your *.exe, and
a resource-only DLL in German. You name that YourProgramDEU.dll (DEU
is LOCALE_SABBREVLANGNAME passed to GetLocaleInfo using locale ID
(LCID) of your user). You start your program under Windows in German
and MFC did it all for you.

^^^If you want your users to use Windows in one language, but only
your program in another, you have to store e.g. a desired LCID
somewhere and, upone startup of your program, use AfxLoadLibrary and
AfxSetResourceHandle manually. You should be able to find this
approach on CodeProject.

2. Use "SetThreadLocale()". But I don't the exactly usage of this API. Is there any sample about this API?

Ah, that's something else. Did you read the doc for that? It says
clearly "don't use it". That is useful if you put multiple same
resource in multiple languages in one *.rc, but that is AFAIK a
practice abandoned in favor of resource DLLs, so it's kinda
irrelevant.


3. Is there the third way to do multi-language support without define "UNICODE"?

You are mistaken. Multi-language support and Unicode, from the
standpoint of providing UI in multiple languages, are orthogonal
issues. Using Unicode is essential if you want your program to work
well WRT __user input__ in different languages. If your program is not
in Unicode, users can only enter text in language defined in Control
Panel->Regional and Language Options->Administrative->"Language for
non-Unicode programs" and English (and the fact that English works is
mostly by historical accident ;-) ).

Goran.
.

Relevant Pages

  • Re: internationalisation
    ... So, for dialogs, we keep all of a projects dialogs in the exe rather than ... separate copies in each language dll. ... It shows you how to build dialogs without resource files. ...
    (microsoft.public.vc.mfc)
  • Re: ? Segregating a Dialogs Code (Particularly Resources)
    ... I typically put all of the common code in a single Dll, ... the projects that need access to the common code. ... Now the problem with my solution is that if one control, ... both resource files and drag the resources over to the new project. ...
    (microsoft.public.vc.mfc)
  • Re: multi-process singleton DLL
    ... creates an IPC server and manages the DLL resource. ... They both interface using this DLL I wrote to take care ... communicate with the IPC server, ... could bind to the protocol driver, the other would get "The requested ...
    (microsoft.public.vc.language)
  • Re: multi-process singleton DLL
    ... creates an IPC server and manages the DLL resource. ... They both interface using this DLL I wrote to take care ... communicate with the IPC server, ... procedure of opening the protocol driver and binding to it. ...
    (microsoft.public.vc.language)
  • Re: Creating a DLL and calling it from an app
    ... Compile your ActX DLL into a resource file, ... At execution time, before you access the dll, load the dll into ...
    (microsoft.public.vb.general.discussion)
Loading