multiple language support: dialog-boxes
in [MFC]
|
Prev: I love MFC!
Next: Using CMFCToolBar and CMFCMenuBar?
From: Joseph M. Newcomer on 19 Jun 2010 10:09 See below... On Sat, 19 Jun 2010 02:35:23 -0700 (PDT), mfc <mfcprog(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()? **** What does OnPaint have to do with any of this? (of course, you would not be doing ANYTHING in OnPaint other than painting!) Since you have not shown the OnPaint handler, the answer is: who knows? joe **** > > >> >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. > > 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 19 Jun 2010 10:15 See below... On Sat, 19 Jun 2010 03:11:27 -0700 (PDT), mfc <mfcprog(a)googlemail.com> wrote: >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 **** Anything other than the CWinApp class accessing 'theApp' (or AfxGetApp()) is very suspect. Why is code to manipulate TheApp not part of the CWinApp-derived class? If this code is manipulating the CWinApp-derived class, this handler should be part of the CWinApp-derived class, not the main frame! Oh, I see. To avoid a "global variable", you tossed some random stuff into the CWinApp class. As a style, this sucks. In fact, I cannot see the relevance of the variable in the CWinApp-derived class, other than some weird belief that "global variables are bad". Putting this in the CWinApp class gives you a global variable that violates module boundaries, which is worse. If it is a global variable (as it should be) and you are OO-fixated, make it a singleton class. You should NEVER include the CWinApp header file anywhere other than the CWinApp class (due to slovenly programming practices, VS 2010 misuses the CWinApp-derived class, and creates an exception to this rule). It is a serious dersign error that the MFC framework includes this header file in every class specification. joe **** > > > 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? 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 19 Jun 2010 10:20 See below... On Sat, 19 Jun 2010 04:56:30 -0700 (PDT), mfc <mfcprog(a)googlemail.com> wrote: >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.... **** No, it looks fine. Key here is that you have to switch languages in the InitInstance handler. **** > >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. **** Switching the resource which is the SDI CFormView is much harder. What you have to do is create a new CFormView using the new dialog template, attach it to the document, and destroy the original CFormView. Note that you should use UpdateAllViews with a nonzero lHint to tell any existing view to store its control contents in the document, and upon completion, use UpdateAllViews with a different nonzero lHint to tell the form to retrieve any existing data from the document and put it into the current view. Otherwise, if you switch views with information in the controls, the information would be lost. See the MSDN example on how to switch views of an SDI app. joe 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 11:12 On 19 Jun., 16:20, Joseph M. Newcomer <newco...(a)flounder.com> wrote: > See below... > > On Sat, 19 Jun 2010 04:56:30 -0700 (PDT), mfc <mfcp...(a)googlemail.com> wrote: > >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.... > > **** > No, it looks fine. Key here is that you have to switch languages in the InitInstance > handler. > **** > > >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. > > **** > Switching the resource which is the SDI CFormView is much harder. What you have to do is > create a new CFormView using the new dialog template, attach it to the document, and > destroy the original CFormView. Note that you should use UpdateAllViews with a nonzero > lHint to tell any existing view to store its control contents in the document, and upon > completion, use UpdateAllViews with a different nonzero lHint to tell the form to retrieve > any existing data from the document and put it into the current view. Otherwise, if you > switch views with information in the controls, the information would be lost. > > See the MSDN example on how to switch views of an SDI app. > joe That means every dialog box (having the same content but for a different language) has its own id (id for the main-dialog in English ! = id for the main-dialog in German)? Moreover you will need a different CFormView-Class for every language and for every dialogbox? Ok it doesn`t matter how many classes a project will include... All the stuff to change the view is correct placed in the mainframe class? CRuntimeClass* pNewViewRTClass; CView *pOldView; pOldView = GetActiveView(); // load the specific view to be the current view (only a demo-example with one view) pNewViewRTClass = RUNTIME_CLASS(CMLSampleView); if(m_pCFirstView == NULL) { m_pCFirstView = STATIC_DOWNCAST(CView, pNewViewRTClass- >CreateObject()); m_pCFirstView->Create(NULL,NULL,AFX_WS_DEFAULT_VIEW,rectDefault, this,AFX_IDW_PANE_FIRST+1,NULL); m_pCFirstView->OnInitialUpdate(); } m_pNewView = m_pCFirstView; int nChildId = m_pNewView->GetDlgCtrlID(); m_pNewView->SetDlgCtrlID(AFX_IDW_PANE_FIRST); pOldView->SetDlgCtrlID(nChildId); CDocument *pDoc = pOldView->GetDocument(); pDoc->AddView(m_pNewView); pDoc->RemoveView(pOldView); pDoc->m_bAutoDelete = FALSE; SetActiveView(m_pNewView); RecalcLayout(); m_pNewView->ShowWindow(SW_SHOW); pOldView->ShowWindow(SW_HIDE); Or is it better to Destroy the old window? pDoc->UpdateAllViews(NULL); will only call the active view in a sdi application where only one view could be availabe at the same time.... But all the stuff (information in the controls; e.g. checkbox is checked or not) have to be stored and loaded to the new view.... where is the best place to do this step by step in the above code?
From: mfc on 19 Jun 2010 13:16
ok I`ve tried to add a demo modification in the OnUpdate() handler. void CMLSampleView::OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint) { if(pSender == NULL) return; //after startup oninitialupdate CButton * button = (CButton *)pSender->GetDlgItem(IDC_CHECK1); UINT test = button->GetCheck(); if(button->GetCheck() == BST_CHECKED) TRACE("checked\n"); CView::OnUpdate (pSender, lHint, pHint); } It`s only a small demo - I already know that GetDlgItem is not the best solution as well as the general id - but it should only help me to get an idea.... of how it could / should work... Moreover all checkboxes or other information from the dialog has to be checked and stored in private variables in the view-class?? And loaded to the new language dialog box? Therefore I added following lines to the code above CDocument *pDoc = pOldView->GetDocument(); pDoc->AddView(m_pNewView); pDoc->UpdateAllViews(pOldView); So there`s first of all the old-view loaded (and the onupdate-method for this oldview to store all these information) - and after that the new view OnUpdate()-method is loaded to get these information back from the private variables from the document... |