|
Windows XP and 7, Visual Studio 2008 and 2010, MFC, C++
Application A supports Unicode and application B does not. Class Log_Writer does not support Unicode. Both applications use Log_Writer ok passing a char * to log writer.
The problem is within Log_Writer when it cannot open the log file. It uses AfxMessageBox() to display an error to the user. When Log_Writer is compiled within the A environment the error message is:
None of the 2 overloads could convert all the argument types.
What can be done so that Log_Writer will work in both environments?
Thanks for your time
|
|
|
|
|
What is that actual code where the error is given?
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
the code is
AfxMessageBox("Unable to open log file");
If I pass it a CString it is okay as in:
CString x;
x.Format( L"stuff" );
AfxMessageBox( x );
But that does not compile in the non unicode project. I am hoping for something that will compile in both worlds.
EDIT: It finally occurred to me that there might a a define for unicode,..., and there is. A bit of googling showed me that using a #ifdef _UNICODE etc will resolve the problem.
Still, is there a way to write the code that will compile in both worlds?
Thanks for your time
modified 14-Jan-13 15:03pm.
|
|
|
|
|
x.Format( L"stuff" );
is wrong for ASCII based compiles, since the L prefix generates a Unicode string. Use the _T() macro around all your string and character constants and they will be correctly generated as ASCII or Unicode depending on the project settings. Note, do not forget to #include <tchar.h> for the foregoing macro.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
bkelly13 wrote: EDIT: It finally occurred to me that there might a a define for unicode,..., and there is. A bit of googling showed me that using a #ifdef _UNICODE etc will resolve the problem. You should use the Project Properties -> General -> Character Set, to select Unicode or ASCCII for your project.
|
|
|
|
|
If you are writing code for windows NT and not for Win9x and its friends then forget about the A version of your program and simply stop maintaining it. This results in much less trouble for programmers, cleaner easier to read code. Actually WinNT uses utf16 internally so all A functions are just functions that do string conversions before and/or after calling a W version. Win9x is almost dead and the same is true for the A version of programs that is simply a heritage from old times.
|
|
|
|
|
You have a good point. My problem (and notice my phrasing) is that I dislike unicode. All the various option make dealing with it an absolute pain.
If you (you in the general sense) want to use computers, then it is time to exit the hieroglyphics epoch and move into the age of alphabets. If you cannot fit your character set into 256 limit then, in my not so humble opinion, you do not have an alphabet.
Yeah, I know I may be in the minority, and no, this is not intended as the start of a flame war. Just my opinion.
I have spent "WAY" too much time trying to figure out the syntax of dealing with unicode. And finally, I work in the military world and my code will never ever be used in the world of hieroglyphs. Straight up ASCII is much easier to deal with.
Thanks for your time
|
|
|
|
|
You have to deal with unicode if you make applications to sell worldwide. 256 characters isnt enough for example for chinese character sets (maybe for simplified chinese) and china is a big market. Unicode isnt so painful if you use utf8 that is more natural to use in C/C++ program because you can write "string" instead of L"string" and you have to convert from utf8 to utf16 only when you call winNT api. Thats what I usually do and this way your program becomes easy to port to other platforms too (linux, mac, ...).
|
|
|
|
|
Review all the macros available to help with unicode/non-unicode compilations from MFC:
What are TCHAR, WCHAR, LPSTR, LPWSTR, LPCTSTR (etc.)?[^]
If you don't want to use MFC, you can always make your own macros to do the same thing... they're all relatively straight forward.
|
|
|
|