|
|||
|
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Usage - Three simple steps to localize > Using localized resources (subfolders?) for MFC, C++
|
|
|||
|
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Usage - Three simple steps to localize > Using localized resources (subfolders?) for MFC, C++
|
| Moderated by: Renate.Reinartz, Markus.Kreisel, Jaakko.Salmenius, Ilkka.Salmenius |
|
||||||||||||||||
| Using localized resources (subfolders?) for MFC, C++ - Usage - Three simple steps to localize - Technical Support (You need to be registered at the forum to write) - .NET, Delphi, ... - Sisulizer Localization Tool Support | |||||||||||||||||
| Author | Post | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||
|
Christine Member
|
Dear all, my software developer colleague got a bit stuck, maybe you could help. So far, we are using multilanguage files for MFC code. We would like to switch to separate resource files, ideally in a subfolder. We tried the following: Without a subfolder (option "<body><mfc>.dll"), setting the language seems to be working out of the box, i. e. the correct language is used by the application. However, with option "<sl>\<body><mfc>.dll", see screenshot, it does not. Only the original strings are shown. (We are calling languages with Country = Neutral, i. e. without sublanguages.) It would be very nice if you could give us a hint or a link to a documentation on the matter. Thanks very much in advance, Christine Attachment: Sisulizer_Visual++Settings.png (Downloaded 22 times)
|
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Janusz Grzybek Super Moderator 
|
MFC always looking for resource dlls in exe directory. If MFC doesn't find appropriated DLL, used are resources from exe file. This is MFC limitation. Best, Janusz
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Janusz Grzybek Super Moderator
|
More information about MFC's resource DLLs you can find in this topic of our online help: http://www.sisulizer.com/online-help/MfcResourceDllFiles.htm Best, Janusz
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Markus.Kreisel Administrator 
|
Hi, To my knowledge does the MFC handle the loading of the language files. So the default file pattern in Sisulizer is in the way the MFC wants to see the files at runtime. That is the reason why it finds the files if you are following the default and it doesn't if you "hide" them in a sub dir. btw: in .NET this was changed. there the resource files have to be in sub dirs. Perhaps because so many customers requested sub dirs?... Markus
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Christine Member
|
Ok, thanks a lot for the clarification and fast response!!! Christine
|
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Christine Member
|
_(at)_Markus: Yeah, our other projects are in DotNet, that's much better... Actually, we will have several hundreds of MFC resources in our main program folder, that's simply not so very convenient. So I spotted the option in Sisulizer and thought maybe there is a way we did not think about.
|
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Markus.Kreisel Administrator
|
Perhaps you could link these resources into a big one before you localize them? I'm not a MFC developer so please don't hit me if this impossible due to some reason :-) Markus
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
ngallimore Member
|
Hi Christine, There are actually two ways to achieve this. Both require some tampering with the way that MFC loads resources, but fortunately MFC is set up to allow that tampering so it's fairly low-risk. The first option is to override CWinApp::LoadAppLangResourceDLL in your CWinApp-derived class. If you look at the default implementation of this in the MFC source (in C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\appcore.cpp) it is fairly simple: figure out the path and filename of the principle executable, and pass that to AfxLoadLangResourceDLL. By overriding this and supplying your own path and then calling AfxLoadLangResourceDLL manually, you can force MFC to load resources from a subdirectory. The second option is to bypass or override the loading of the resources entirely by directly setting CWinApp::m_hLangResourceDLL, which is the handle of the satellite resource DLL to use (and is protected, so can be directly modified from your CWinApp-derived class). This allows you to completely use your own logic to track down whichever resource DLL you wish to use. Just make sure to call ::FreeLibrary on the previous value before overwriting it, otherwise you'll get a memory leak. Hope this helps. It's all based on VS2008, but should be adaptable to previous versions should that be an issue. Let me know if you need more info. Regards, Nick
|
||||||||||||||||
| |||||||||||||||||
| Current time is 06:26 am | |
| .NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Usage - Three simple steps to localize > Using localized resources (subfolders?) for MFC, C++ | |
Sisulizer software localization tool - Three simple steps to localize
