multiple language support: dialog-boxes
in [MFC]
|
Prev: I love MFC!
Next: Using CMFCToolBar and CMFCMenuBar?
From: Mihai N. on 20 Jun 2010 16:02 > InitCommonControls(); > SetRegistryKey(_T("Local AppWizard-Generated Applications")); > m_LanguageSupport.LoadBestLanguage(); // <-- Add this line (after the > call to SetRegistryKey) > LoadStdProfileSettings(4); Yes, that is the perfect place :-) -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: Mihai N. on 20 Jun 2010 16:04 > With the *old* menu structure generated by the AppWizard, it isn't hard to > do it on the fly. Just load the new menu from the DLL for Document present > (hMenuDoc) and no Document present, (hMenuNoDoc) and then: I know. But the more things you have, and the further you evolve from the bard-bone MFC application generated by MFC, the messier it gets to track and update everything. It is not impossible, just not worth the effort :-) -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: Joseph M. Newcomer on 20 Jun 2010 17:39 See below... On Sun, 20 Jun 2010 10:19:05 -0700 (PDT), Goran <goran.pusic(a)gmail.com> wrote: >On Jun 19, 4:15�pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: >> 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. > >Yes, yes, yes. > >To expand: doing this as a matter of fact, over time, creates MASSIVE >compile-time dependencies. I have that (decade,5 old code base). I >can't tell how much I've come to despise them. I really wish MSDN said >something on the lines of "never add, only override, members of >CWinApp" from the get go (when I was learning it). In fact, I remember >tutorials saying quite the opposite. :-( > **** My view: if you need a piece of global state, declare an instance of it in a TOTALLY SEPARATE .cpp file, and create a TOTALLY SEPARATE .h file to hold the extern declaration. One of the absolutely WORST ideas that every newbie seems to fall prey to is the idea that creating a new file is a MORTAL SIN and it is essential to shoehorn everything into as few files as possible, preferrably NEVER creating a new file. This is the sure mark of an amateur. If you don't have the guts to create files like DebugMask.h extern DWORD DebugMask; #define SOME_DEBUG_OPTION 1 #define ANOTHER_DEBUG_OPTION 2 #define YET_ANOTHER_OPTION 4 where those names have significance, and creating DebugMask.cpp: #include "stdafx.h DWORD DebugMask; then you should get out of the business. The notion of tossing every single random utility function into some generic soup-pot (such as the CWinApp-derived class, or, worse still, some funky file with some stupid name like "util.cpp" is a mistake which haunts this profession. >I also wish tutorials said: "apply interface segregation principle to >your document class", for same compile-time dependencies reason. But I >can't blame MFC people for that; I don't think ISP was even formulated >when MFC was coming out :-(. **** We knew this technique decades before C++ was a gleam in Stroustrup's eye. We knew about interfaces, modularization, etc. by the mid-1970s and were developing languages to support these concepts. The notion that creating a file is a Really Bad Idea seems to grow from failures to provide any form of education whatsoever, and is not helped by horrendously bad examples in books that claim to "teach programming". ISP is just a formalization of modular interfaces that pretends like it is a Really New Idea, when in fact it is just a TLA (Three-Letter Acronym) applied to an old, old idea. For years I claimed that there were two Really Evil practices in programming: (1) tossing everything into a single "util" file (2) doing a #include "everything.h" where "everything.h" was nothing more than a long list of #includes One of my students proved beyond any shadow of a doubt that both these ideas are not supported by any form of reality we live in, and at best are the horrible ideas of deeply lazy programmers who should not have been allowed into the profession. She came up with the actual numbers to show that both of the above ideas are *provably* Bad Ideas. And she has the numbers to show it. See: Ellen Borison: "Program Changes and the Costs of Selective Recompilation", Ph.D. dissertation, Computer Science Department, Carnegie Mellon University, August, 1989. There is a constant myth, probably propagated by people who are clueless, that fewer files compile faster Ellen proves this is a myth. joe ***** > >Goran. 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 20 Jun 2010 17:42 I just SendMessage to the main window and let it do a SendMessageToDescendants(UWM_LANGUAGE_DLL_CHANGE); and each child deals with whatever it cares about. The main frame reloads the menu. joe On Sun, 20 Jun 2010 13:04:15 -0700, "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote: > >> With the *old* menu structure generated by the AppWizard, it isn't hard to >> do it on the fly. Just load the new menu from the DLL for Document present >> (hMenuDoc) and no Document present, (hMenuNoDoc) and then: > > >I know. But the more things you have, and the further you evolve from the >bard-bone MFC application generated by MFC, the messier it gets to track >and update everything. > >It is not impossible, just not worth the effort :-) 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 21 Jun 2010 03:54
On 20 Jun., 22:02, "Mihai N." <nmihai_year_2...(a)yahoo.com> wrote: > > InitCommonControls(); > > SetRegistryKey(_T("Local AppWizard-Generated Applications")); > > m_LanguageSupport.LoadBestLanguage(); // <-- Add this line (after the > > call to SetRegistryKey) > > LoadStdProfileSettings(4); > > Yes, that is the perfect place :-) > > -- > Mihai Nita [Microsoft MVP, Visual C++]http://www.mihai-nita.net > ------------------------------------------ > Replace _year_ with _ to get the real email Thanks for the response, but is it not a bad practice to add a global variable m_LanguageSupport to the CWinApp-class? At the moment it seems to me, that it is only possible to add a static method to the LanguageSupport.class to load the correct dll at startup. And if the user tried to change the language later, I`ve to check which language dll is loaded at startup because the variable m_LanguageSupport won`t have any information at this moment (cause in the static method I`ve no chance to set any global variable.-...) Maybe I don`t need this global variable if I always take a look at ((LANGID)AfxGetApp()->GetProfileInt(_T(""),szLanguageId,0);) to get the current language dll... |