|
I'd like my application to show English text in menus, messages, etc for English-speaking users and Japanese text for Japanese-speaking users. Can I do this with a single version of my application or do I need to make an separate build of my application for each language?
|
|
|
|
|
you don't need to build separate versions for defferent languages.
you can do this via at least 3 ways:
1, make a different resource for each language and load it dynamiclly
2, use .INI file,
3, use XML tech,
|
|
|
|
|
You can use translated resouce DLLS. I personally dislike that solution though becaues it means you have to maintain two sets of resources.
What I've done for i18n (that's short for internationalization) is to take out all strings from the code and resouces, and replace them with identifiers. I then have translated text files that look like this:
(English file)
MessageBoxString=This is a message in English.
...
(Japanese file)
MessageBoxString=This is a message in Japanese.
Very flexible, easy to translate, and easy to add new languages. You just have to make sure all text boxes, etc. are big enough for strings in either language.
One thing to beware of witih Japanese - it is a double-byte character set. So that means your app either has to have MBCS enabled, or use Unicode. If you are running on an English system, your text will look like garbage unless you have Japanese fonts installed.
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
Win32 apps can have multiple languages in a single EXE or DLL. If you look in your .RC file, most have a section like this:
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
#ifdef _WIN32
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
#pragma code_page(1252)
#endif //_WIN32
You can define similar sections for each of the languages you wish to support. When your application loads resources, Windows will choose the appropriate language section based upon the language settings for the current thread. There are also ways to define 'language-neutral' sections, for things that aren't necessarily language dependent (like icons, for example).
Software Zen: delete this;
|
|
|
|
|
Thank you! This is what I wanted to know.
Is it possible to set up alternate languages through the MSVC++ editor or will I need to edit my .RC file manually?
|
|
|
|
|
Dov Sherman wrote:
Is it possible to set up alternate languages through the MSVC++ editor or will I need to edit my .RC file manually?
In VC6 and VS.NET, select a resource in the Resource View. Then select Insert, and Resource Copy. You'll then be prompted for a language. This inserts a copy of an existing resource, but marked for the new language.
Software Zen: delete this;
|
|
|
|
|
Thank you! That just leaves the question of how to test the internationalization once I implement it. Is there a way to trick my computer into thinking it's French?
|
|
|
|
|
i write a class with VC,but why so many warnings?
i doubt it's come from my virtual class.but why?
see my source code following:
virtual class:
ZDataFile.h:
class ZDataFile
{
public:
virtual void SetSpliter(string strSpliter) = 0;
virtual vector<vector<string> *> LoadData() = 0;
virtual vector<string> LoadLine(int iLinNum) = 0;
virtual vector<string> LoadColumn(int iColNum) = 0;
};
subclass:
#include "ZDataFile.h"
class ZTxtDataFile : public ZDataFile
{
public:
ZTxtDataFile(const char *FileName);
virtual ~ZTxtDataFile();
private:
string Spliter;
vector <vector<string> *> FileData;
ifstream *myfile;
};
.cpp
ZTxtDataFile::ZTxtDataFile(const char *FileName)
{
myfile = new ifstream(FileName);
if(myfile->fail())
{
throw "can not open file!";
}
}
ZTxtDataFile::~ZTxtDataFile()
{
delete myfile;
}
the warning is:
documents\vc\stabctrl_demo\test\zdatafile.h(23) : warning C4786: 'std::vector<std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char
_traits<char>,std::allocator<char> > > > *,std::allocator<std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > *> >' : identifier was
truncated to '255' characters in the debug information
|
|
|
|
|
The compiler doesn't like some STL related stuff. Have a look at http://www.bdsoft.com/tools/stlfilt.html[^]... atleast it helps a little bit.
"was wir auch tun, wohin wir gehen
die illuminaten sind im system
sie kontrollieren überall
und 23 ist ihre zahl!"
23, welle: erdball
|
|
|
|
|
That "identifier too long" warning is harmless, you can turn it off with a #pragma
--Mike--
THERE IS NO THERE IS NO BUT THERE IS
MAGIC PIXIE DUST BUSINESS GENIE CODE PROJECT
Homepage | RightClick-Encrypt | 1ClickPicGrabber
"You have Erica on the brain" - Jon Sagara to me
|
|
|
|
|
I'm having a really hard time getting this function to properly find a file. I know I'm supposed to use the registry for app initialization info, but I've got an old app and DLL that use an INI file and I need to continue supporting it.
I'm just trying to read from a file called "api.ini" in the same directory as the application. Of course, that directory is not known at compile time. I determine the directory using GetModuleFileName() and append api.ini to the full path. Then I convert all '\' chars to '\\' since that is how the func needs it. This never works!
If I put the api.ini file in the WINNT directory, and only pass "api.ini" as the last param to GetPrivateProfileString(), it properly finds the file. If I hard code the full path ("c:\\program files\\test\\api.ini"), the function finds the file IF the application is run from a different directory (the VS 6.0 dev environment.) However, if I place the app in the c:\program files\test\ directory, then it fails and can't find the file.
Does anybody know why this is not working for me? It seems so simple...I assume I'm missing something really easy. I should be able to just pass the full path to the file and have it read properly. By the way, I have verified that the path I pass to GetPrivateProfileString() is the correct, full path.
Any help would be greatly appreciated. 
|
|
|
|
|
Justin Cooke wrote:
Then I convert all '\' chars to '\\' since that is how the func needs it.
You don't need to convert \ to \\, it's only for hardcoded strings you do that.
Try ´not to, and see if it don't help...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Thanks for the suggestion, but it didn't seem to help. It's very odd, now that I'm not modifying the string at all (leaving the single slashes alone), I'm passing the same file path string to GetPrivateProfileString() that I pass to CStdioFIle::Open(). The file opens properly, but GetPrivateProfileString() can't find it (it returns the default value.)
Does anyone have any other ideas? Could it have something to do with the fact that this is MFC?
Thanks.
|
|
|
|
|
Have you debugged the app to see what GetModuleFileName() is returning? It should retrun a fully qualified path (i.e., the filename is included). You have to remove the filename before appending another filename.
char szBuffer[MAX_PATH] = {0};
GetModuleFileName(hInstance, szBuffer, sizeof(szBuffer));Something like the above will give you C:\My Path\myfile.exe. You'll have to drop myfile.exe before you add the other filename or else you'll get C:\My Path\myfile.exe\api.ini.
Oh, and like it was stated, you don't need to escape the backslash unless it's a string literal (i.e., you're typing it in the code directly).
Jeremy Falcon
"so be it, threaten no more, to secure peace is to prepare for war" - Metallica
|
|
|
|
|
I think the two suggetions mentioned will work for you. That being said, I feel it is my duty to point out one thing: GetPrivateProfileString is EVIL. If you ever run on a 9X box and your INI file gets to be bigger than 64K, it will mysteriously fail, and you will spend a lot of time tracking it down.
I'd personally recommend using an INI clas (I'm sure there's one here on CP - or you can write your own), or write some simple routines to parse a text file and get the info you need.
Yes, it IS more work to do it that way, but you have more control, and aren't subject to 64K limitations. 
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
I have an MFC app that links several libs and DLLs. Does it matter how my libs and DLLs were built, whether it is Multithreaded or Multithreaded DLL, as long as they link? I'm just not sure whether everything is totally working yet.
If my app is compiled as "multithreaded DLL", must all my DLLs and libs be compiled the same way to work properly?
In one case, UNZDLL.dll (a dll for unzipping files) doesn't seem to work right when called from a DLL at all, however it is built (I don't know how this one was built). I'm just trying to eliminate some possibilities.
Thanks!
-Aaron
|
|
|
|
|
mixing DLL and libraries compiled with different crt implementations, produces most colorful and difficult errors to diagnose. Typical error is when you create an object in one DLL and try to destroy in the other.
|
|
|
|
|
Uggghhh. Thanks for the foreboding warning. I'll find "multithreaded DLL" versions of those DLLs.
One more question: Do the CRT libs only matter for DLLs and libs that use MFC? I have several DLLs and libs that are not MFC. Do I need to find new versions of those too?
Thanks again.
-Aaron
|
|
|
|
|
It applies to all executables (or almost all). The way windows API avoid the problem is they use some other mechanism to allocate memory (like HeapAlloc, CoTaskMemAlloc) and they do not use global/static variables. You can use a dll with different crt if you absolutely sure there is no memory "exchange" and no global variables (that is why MFC dlls are especially unsafe).
P.S. c++ export dll's, by definition must be used in the same CRT environment they are compiled for.
|
|
|
|
|
How can I know when the app gets minimized?
There is no WM_ for that, or...
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C#, ASP.NET and C++!
|
|
|
|
|
|
Try WM_SYSCOMMAND with WPARAM SC_MINIMIZE.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Thank you both!
I never looked at WM_SIZE that well... 
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C#, ASP.NET and C++!
|
|
|
|
|
Hey, how can you make dc draw commands (like FillRect) in a dialog box? The Dialog is a child of the CDialog class. Thanks
Bob
|
|
|
|
|
Provide a handler for the WM_PAINT message.
Regards,
Alvaro
When birds fly in the right formation, they need only exert half the effort. Even in nature, teamwork results in collective laziness. -- despair.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
