Re: Multiple language code

From:

"David Webber" <dave@musical-dot-demon-dot-co.uk>

Newsgroups:

microsoft.public.vc.mfc

Date:

Sat, 21 Mar 2009 09:27:25 -0000

Message-ID:

<et8awegqJHA.528@TK2MSFTNGP06.phx.gbl>

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message
news:Xns9BD58D48A2C1MihaiN@207.46.248.16...

    class RU
    {
        HINSTANCE hInstOfExe;
        HINSTANCE hInstOfCurrentlyChosenLanguageDLL;

    public:

        CString ruLoadString( UINT nID );
        BOOL ruDoDialogue1( .... );
        BOOL ruDoDialogue2( .... );
        BOOL ruDoDialogue3( .... );
        ....
    };

For example the construction of a dialogue class and call to its
DoModal()
are all done within the ruDoDialogueN( .... ); function.

Why would you want a class for each language? It does not scale very well:
- when you need to add a new language, you need to add a new class
- when you need to add a new dialog, you need to add a method
to 20 classes (for 20 languages)

I think there is a misunderstanding somewhere. Probably me glossing over
details. There is only one such class. Let me explain.

First the members

        HINSTANCE hInstOfExe;
        HINSTANCE hInstOfCurrentlyChosenLanguageDLL;

are in fact

        static HINSTANCE hInstOfExe;
        static HINSTANCE hInstOfCurrentlyChosenLanguageDLL;

so the language DLL in use is always remembered. (Sorry for not mentioning
that).

When you change languages, all that happens is that

hInstOfCurrentlyChosenLanguageDLL

is changed corresponding with the newly loaded language DLL.

I can say a bit more about it:

1. Strings:
Its member for loading strings is very simple (and there is only one!):

static CString RU::ruLoadString( UINT nID )
{
     BOOL bFound = FALSE;
     CString S;

     if( nID )
     {
          if( hInstOfCurrentlyChosenLanguageDLL )
                                    bFound = S.LoadString(
hInstOfCurrentlyChosenLanguageDLL, nID );
          if( (!bFound) && hInstOfExe ) bFound = S.LoadString( hInstOfExe,
nID );
     }

     return S;
}

This can be called anywhere simply with

    CString S = RU::LoadString( nID );

and it gets the current language.

2. Menus:
It also has a member

static HMENU RU::ruLoadMenu( WORD nMenuId );

which is used to switch the menu to the new language of course. (This
wasn't static until I got involved in this discussion and saw that it should
have been!).

3. Dialogue boxes:

It *does* have one (non static) member for each modal dialogue box, but you
have to have a function somewhere which constructs the dialogue and calls
its DoModal(). I just put them all in members of my resource access class.

The RU class has another data member

        HINSTANCE hOldInstance;

This one is definitely not static:

The RU constructor does:

    hOldInstance = AfxSetResourceHandle();
    AfxSetResourceHandle( hInstOfCurrentlyChosenLanguageDLL );

to get the desired language module and remember the old resource handle in
hOldInstance. The destructor does

    AfxSetResourceHandle( hOldInstance );

In between the dialogue-handling member is called and automatically gets the
correct language resource. Data chosen in the dialogue is returned via
arguments of the function. So schematically it would be

    {
        RU ru; // sets the resource handle.

        BOOL bResult = ru.editTempo( TEMPO &tempo );

        if( bResult )
        {
            // Apply the new tempo...
        }
    } // RU destructor resets resource handle.

Note that the dialogue template IDs in the different language resource
modules correspond exactly, so that the ru.editTempo(); method just loads
the template for the tempo-editing dialogue with IDD_TEMPOEDIT - it knows
nothing of which language the user is seeing (which is by then implicit in
the current resource handle).

4. But this is already probably more than you wanted to know. :-) I'm
sure there are lots of ways of handling the details - but it *doesn't* imply
a different class for each language.

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm