From: Joseph M. Newcomer on
Short of single-stepping through the code, I have no idea how to tell why it failed.

Have you tried this?
joe

On Fri, 18 Jun 2010 13:57:55 -0700 (PDT), mfc <mfcprog(a)googlemail.com> wrote:

>On 18 Jun., 21:55, mfc <mfcp...(a)googlemail.com> wrote:
>> On 18 Jun., 20:41, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
>>
>>
>>
>>
>>
>> > Why is there *any* button called "btn1". �The FIRST thing you do when creating controls is
>> > change all those stupid default IDs (e.g., IDC_BUTTON1) to something meaningful (e.g.
>> > IDC_ASK_USER_FOR_NAME). �Only then do you start to create variables (which will have
>> > meaningful names, like c_AskUserForName) and handlers (e.g., OnBnClickedAsUserForName).
>>
>> > So already you are digging yourself into a pit of unmaintainability.
>>
>> > On Fri, 18 Jun 2010 10:30:36 -0700 (PDT), mfc <mfcp...(a)googlemail.com> wrote:
>> > >Hi,
>>
>> > >I`ve a sdi application where I want to add multiple language support.
>> > >If the user press the button btn1, the language should be changed.
>>
>> > >After the OnButtonClick-Function I`m using SendMessage to send a msg
>> > >to one function in the mainframe-class
>> > >(class CMainFrame : public CFrameWnd)
>>
>> > >This is the function in the CMainFrame() - only a small demo:
>>
>> > >HINSTANCE hInst = NULL;
>>
>> > >if(!m_hInstGerman)
>> > > � �m_hInstGerman = LoadLibrary(_T("LangDeu.dll"));
>>
>> > ****
>> > There are so many things wrong with the above code I cannot hope to list all of them.
>>
>> > Why is there an m_hInstGerman? �Do you plan to add a variable for each of the several
>> > hundred languages supported? �Will there be an hInstItalian_Italy, hinstItalian_Swiss, an
>> > hInstSpanish_Mexican, an hInstFrench_Canadian? �Of course not. �One local instance
>> > variable will suffice for all possible languages and that's all you should ever need. �In
>> > the worst case, using a simple std::map to map language abbreviations to DLL handles might
>> > be used, if you want to support the user dynamically switching languages. �Or, you can
>> > compute the DLL name (GetModuleFileName) and only load the DLL if the name you get is
>> > different from the one you have (don't forget to FreeLibrary the one you are about to
>> > replace!)
>>
>> > Why are you not forming the name from the user's current selected active language? �Why
>> > did you hardwire it to "LangDeu.dll"?
>>
>> > Do you plan to add code like the above for each of the hundreds of languages supported by
>> > Windows?
>>
>> > Play with my Locale Explorer (see my MVP Tips site). It will even generate the code for
>> > you!
>>
>> > From the Locale Explorer:
>>
>> > // LOCALE_SABBREVLANGNAME
>> > CString sabbrevlangname_data;
>> > LCID lcid = LOCALE_SYSTEM_DEFAULT;
>> > { /* get LOCALE_SABBREVLANGNAME */
>> > �LPTSTR p = sabbrevlangname_data.GetBuffer(4);
>> > �VERIFY(::GetLocaleInfo(lcid, LOCALE_SABBREVLANGNAME, p, 4));
>> > �sabbrevlangname_data.ReleaseBuffer();} /* get LOCALE_SABBREVLANGNAME */
>>
>> > // ... use sabbrevlangname_data here
>>
>> thanks for all these information. Do you know which steps I`ve to do
>> to start a new dll (during running the programm)? Or is it only
>> possible to restart the programm to start a new dll???
>>
>> All the steps which are necessary after loading the new dll file with
>> LoadLibrary()...- Zitierten Text ausblenden -
>>
>> - Zitierten Text anzeigen -
>
>I`ve found a good working example besides the effect that the language
>didn`t change the dll on-the-fly
>http://read.pudn.com/downloads83/sourcecode/chinese/319271/LanguageSupport.cpp__.htm
>
>
>void CLanguageSupport::OnSwitchLanguage(UINT nId, bool
>bLoadNewLanguageImmediately)
>with bLoadNewLanguageImmediately = TRUE;
>
>Everything seems to be ok, but it doesn`t work... maybe you know where
>the problem would be?
>
>best regards
>Hans
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on
Note also that features that *require* correct settings in the Registry are *very*
suspect. You *must* assume that *no* Registry key or value is defined, and do something
intelligent anyway. Defaulting to the default user locale is a good approach. I refuse
to use SetRegistryKey because of all the problems it has.
joe

On Fri, 18 Jun 2010 17:00:22 -0400, Joseph M. Newcomer <newcomer(a)flounder.com> wrote:

>See below...
>On Fri, 18 Jun 2010 12:55:24 -0700 (PDT), mfc <mfcprog(a)googlemail.com> wrote:
>
>>On 18 Jun., 20:41, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
>>> Why is there *any* button called "btn1". �The FIRST thing you do when creating controls is
>>> change all those stupid default IDs (e.g., IDC_BUTTON1) to something meaningful (e.g.
>>> IDC_ASK_USER_FOR_NAME). �Only then do you start to create variables (which will have
>>> meaningful names, like c_AskUserForName) and handlers (e.g., OnBnClickedAsUserForName).
>>>
>>> So already you are digging yourself into a pit of unmaintainability.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, 18 Jun 2010 10:30:36 -0700 (PDT), mfc <mfcp...(a)googlemail.com> wrote:
>>> >Hi,
>>>
>>> >I`ve a sdi application where I want to add multiple language support.
>>> >If the user press the button btn1, the language should be changed.
>>>
>>> >After the OnButtonClick-Function I`m using SendMessage to send a msg
>>> >to one function in the mainframe-class
>>> >(class CMainFrame : public CFrameWnd)
>>>
>>> >This is the function in the CMainFrame() - only a small demo:
>>>
>>> >HINSTANCE hInst = NULL;
>>>
>>> >if(!m_hInstGerman)
>>> > � �m_hInstGerman = LoadLibrary(_T("LangDeu.dll"));
>>>
>>> ****
>>> There are so many things wrong with the above code I cannot hope to list all of them.
>>>
>>> Why is there an m_hInstGerman? �Do you plan to add a variable for each of the several
>>> hundred languages supported? �Will there be an hInstItalian_Italy, hinstItalian_Swiss, an
>>> hInstSpanish_Mexican, an hInstFrench_Canadian? �Of course not. �One local instance
>>> variable will suffice for all possible languages and that's all you should ever need. �In
>>> the worst case, using a simple std::map to map language abbreviations to DLL handles might
>>> be used, if you want to support the user dynamically switching languages. �Or, you can
>>> compute the DLL name (GetModuleFileName) and only load the DLL if the name you get is
>>> different from the one you have (don't forget to FreeLibrary the one you are about to
>>> replace!)
>>>
>>> Why are you not forming the name from the user's current selected active language? �Why
>>> did you hardwire it to "LangDeu.dll"?
>>>
>>> Do you plan to add code like the above for each of the hundreds of languages supported by
>>> Windows?
>>>
>>> Play with my Locale Explorer (see my MVP Tips site). It will even generate the code for
>>> you!
>>>
>>> From the Locale Explorer:
>>>
>>> // LOCALE_SABBREVLANGNAME
>>> CString sabbrevlangname_data;
>>> LCID lcid = LOCALE_SYSTEM_DEFAULT;
>>> { /* get LOCALE_SABBREVLANGNAME */
>>> �LPTSTR p = sabbrevlangname_data.GetBuffer(4);
>>> �VERIFY(::GetLocaleInfo(lcid, LOCALE_SABBREVLANGNAME, p, 4));
>>> �sabbrevlangname_data.ReleaseBuffer();} /* get LOCALE_SABBREVLANGNAME */
>>>
>>> // ... use sabbrevlangname_data here
>>
>>thanks for all these information. Do you know which steps I`ve to do
>>to start a new dll (during running the programm)? Or is it only
>>possible to restart the programm to start a new dll???
>>
>>All the steps which are necessary after loading the new dll file with
>>LoadLibrary()..
>****
>LoadLibrary is all you need to do to load the DLL. The AfxSetResourceHandle makes the DLL
>be the default source for the resources. Note that the DLL has to contain *all* the
>resources you need, not just some, and for safety, the executable should have none of
>these resources. It should only have enough resources to get the system up prior to
>InitInstance, which means, essentially, no resources at all, and a few to report that the
>DLL is missing.
>
>Use the above code to get the 3-letter locale ID (I found that there are five German
>languages supported: Austria, Germany, Switzerland, Leichtenstein and Luxembourg, so
>supporting DEU supports only one of them. And to get the LCID, you would use
>LOCALE_USER_DEFAULT as the constant instead of the MAKELCID macro.
> joe
>****
>>
>>
>>
>>
>>
>Joseph M. Newcomer [MVP]
>email: newcomer(a)flounder.com
>Web: http://www.flounder.com
>MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: mfc on
> >>All the steps which are necessary after loading the new dll file with
> >>LoadLibrary()..
> >****
> >LoadLibrary is all you need to do to load the DLL.  The AfxSetResourceHandle makes the DLL
> >be the default source for the resources.  Note that the DLL has to contain *all* the
> >resources you need, not just some, and for safety, the executable should have none of
> >these resources.  It should only have enough resources to get the system up prior to
> >InitInstance, which means, essentially, no resources at all, and a few to report that the
> >DLL is missing.

>>Short of single-stepping through the code, I have no idea how to tell why it failed.

Of course, the code doesn`t fail, but I also doesn`t get the new menu,
the new dialog box and so on, from the latest loaded dll. Is there any
additional code required in the OnPaint() method
CMyAppView::OnPaint()?


> >Use the above code to get the 3-letter locale ID (I found that there are five German
> >languages supported: Austria, Germany, Switzerland, Leichtenstein and Luxembourg, so
> >supporting DEU supports only one of them.  And to get the LCID, you would use
> >LOCALE_USER_DEFAULT as the constant instead of the MAKELCID macro.
> >                            joe
> >****

If the code is working, I`ll do all these changes to be able to detect
all different languages.



From: mfc on
On 19 Jun., 11:35, mfc <mfcp...(a)googlemail.com> wrote:
> > >>All the steps which are necessary after loading the new dll file with
> > >>LoadLibrary()..
> > >****
> > >LoadLibrary is all you need to do to load the DLL.  The AfxSetResourceHandle makes the DLL
> > >be the default source for the resources.  Note that the DLL has to contain *all* the
> > >resources you need, not just some, and for safety, the executable should have none of
> > >these resources.  It should only have enough resources to get the system up prior to
> > >InitInstance, which means, essentially, no resources at all, and a few to report that the
> > >DLL is missing.
> >>Short of single-stepping through the code, I have no idea how to tell why it failed.
>
> Of course, the code doesn`t fail, but I also doesn`t get the new menu,
> the new dialog box and so on, from the latest loaded dll. Is there any
> additional code required in the OnPaint() method
> CMyAppView::OnPaint()?
>
> > >Use the above code to get the 3-letter locale ID (I found that there are five German
> > >languages supported: Austria, Germany, Switzerland, Leichtenstein and Luxembourg, so
> > >supporting DEU supports only one of them.  And to get the LCID, you would use
> > >LOCALE_USER_DEFAULT as the constant instead of the MAKELCID macro.
> > >                            joe
> > >****
>
> If the code is working, I`ll do all these changes to be able to detect
> all different languages.

if I add these following lines to the code, I`ll get the actual menu
from the latest loaded dll!

void CMainFrame::OnLanguage(UINT nId)
{
theApp.m_LanguageSupport.OnSwitchLanguage(nId); // Creates the
languages sub-menu


CMenu* m_pMenuNew = new CMenu;
m_pMenuNew->LoadMenu(IDR_MAINFRAME);
SetMenu(m_pMenuNew);
}

But which additional steps do I have to do to get the latest dialog
box from the latest loaded dll file?

From: mfc on
The whole application is a sdi application with the doc/view modell;
therefore I`m loading a dialog at the startup with e.g. buttons etc.


CMLSampleView::CMLSampleView()
: CFormView(CMLSampleView::IDD)
{
// TODO: add construction code here

}

IDD is the id from the dialog box, generated by the resoure editor.
I`ve copied this dialog box to the other projects (satellite dlls for
German and for English); Maybe this approach is wrong....

In the end, when the programm is started, the user should see a sdi
window app where he can switch to different languages by some
cbuttons. There will be no menu in the end application.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: I love MFC!
Next: Using CMFCToolBar and CMFCMenuBar?