Prev: I love MFC!
Next: Using CMFCToolBar and CMFCMenuBar?
From: Joseph M. Newcomer on 18 Jun 2010 17:47 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 18 Jun 2010 17:49 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 19 Jun 2010 05:35 > >>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 19 Jun 2010 06:11 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 19 Jun 2010 07:56
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. |