Board index » Visual Studio » Problem when converting to UNICODE, please help

Visual Studio75
Hello,

I didn't think it would be so much pain to convert to UNICODE. The problems

I have so far are:

1. I can't use atof() to convert a string to float number. Someone said to

use _tstof() (wtof()). But my version of VS6 doesn't have that (not in my

MSDN either - July2001). Someone must have done unicode at that time. What

was the solution then?

2. It is so odd that I can't use _tcsncpy() or lstrcpyn() to copy 2 strings,

eg.

CHARFORMAT cfThis;

LPCTSTR sFaceName;// from calling function

_tcsncpy(cfThis.szFaceName, sFaceName, LF_FACESIZE);

The message is {cannot convert parameter 1 from 'char [32]' to 'unsigned

short *'; Types pointed to are unrelated; conversion requires

reinterpret_cast, C-style cast or function-style cast}

cfThis.szFaceName is TCHAR[], in unicode it would have been WCHAR[], I don't

know why it becomes char[32]. Can someone help please?

3. strstream doesn't seem to work in unicode. What is the alternative?



Please help. Thanks.



XL


-

CHARFORMAT will become CHARFORMATA or CHARFORMATW based on whether you

have the 'UNICODE' symbol defined. From the warning < cannot convert

parameter 1 from 'char [32]'>, it seems that you do not have the UNICODE

symbol defined.



--

Cheers

Check Abdoul [VC++ MVP]

-----------------------------------



"XL Zhou" <xuelong@pvtprop.com>wrote in message



-

Have you ever succeed to work with Unicode

just try this AfxMessageBox(L"Hello Unicode"); // don't forget the L before

". See compiler flag (check _UNICODE is defined)



1) Have you really tried to call _wtof ? (don't forget underscore! ). Don't

also forget to include <stdlib.h>or <wchar.h>



2) You want to copy a WCHAR* into a char*, it cannot work. Why char[32]?

there has to be something to do with the way you have declared your

szFaceName.you need to convert sFaceName in char* before like this :



char szFaceName[32];

wcstombs(szFaceNamen, sFaceName , sizeof(szFaceName) );



and only after you can do :

_tcsncpy(cfThis.szFaceName, szFaceName, LF_FACESIZE);



3) No idea



Hope it will help you a bit







If it really doesn't work you can try these functions but in my opinion it

is better

"XL Zhou" <xuelong@pvtprop.com>a écrit dans le message de



-

"XL Zhou" <xuelong@pvtprop.com>wrote in message

Just for the record, you do have both UNICODE and _UNICODE defined?



I think it'd be sometihing like...



#ifdef _UNICODE

#define _tstof _wtof

#else

#define _tstof atof

#endif



Could you post the smallest complete code sample required to repro this?



I don't really know but maybe this...



http://msdn.microsoft.com/library/default.asp?url" rel="nofollow" target="_blank">msdn.microsoft.com/library/default.asp=/library/en-us/vcstdlib/html/vclrf_sstream_header.asp



--

Jeff Partch [VC++ MVP]







-

Yes, I do have UNICODE and _UNICODE defined in Project

settings->preprocessor. Is this a wrong to define it?



XL



"CheckAbdoul" <checkabdoul at mvps dot org>wrote in message



-

This compiles fine.

But it dosen't link. because:

"msvcrtd.lib(crtexew.obj) : error LNK2001: unresolved external symbol

_WinMain@16"

What is going on here?





I did, it was undefined.



cfThis.szFaceName should have been WCHAR[32] in unicode. But it didn't.



Help please.



XL











-

Okay, I'm convinced. I have no idea what you should do about the missing

_wtof. Although the downloadable PSDK appears to contain the source code for

it. The CHARFORMAT thing happens because 'AfxWin.h' catagorically #defines

_RICHEDIT_VER to 0x0100, and the SDK header 'RichEdit.h' only #defines

CHARFORMAT to CHARFORMATW when _RICHEDIT_VER is>= 0x0200. I can get it to

compile by doing...



#include <afxwin.h>// MFC core and standard components

#undef _RICHEDIT_VER



...in 'StdAfx.h', but I don't know enough about MFC's expectations to say

what side effects giving it the higher version value will have.



Lastly, the linking problem you mentioned in another reply is solved by

adding 'wWinMainCRTStartup' to the Project->Settings->Link->Output->Entry

Point Symbol box.



--

Jeff Partch [VC++ MVP]





-

Thanks, Jeff.

Would you mind sending/posting _wtof() source code? I could download PSDK,

but I would have to install it to see that, right? I am afraid that the new

PSDK may mess up the old one.

I did try to #undef _RICHEDIT_VER and/or re-def it to 0x0210, but it causes

some third party component I use to break down. There must be something else

using the def. I may use CHARFORMAT2 instead of CHARFORMAT to overcome the

problem. But it requires many changes.



XL







-

"XL Zhou" <xuelong@pvtprop.com>wrote in message

Boy, I'm pretty sure 'wtof.c' isn't redistributable that way. FWIW, I have

and use VC6 with the Feb 2003 PSDK installed and first in the include/lib

path without issue, but I don't know which one you're relying on. And as

always: YMMV.

--

Jeff Partch [VC++ MVP]





-

When you install VS6 you also need to install the unicode lib I think. It is

not done by default.I have never found it myself but I read that it is

somewhere on the VS6 cd



"XL Zhou" <xuelong@pvtprop.com>a écrit dans le message de



-

Mostly this comes about by not writing Unicode-aware code. You should not call atof, which

only works on 8-bit characters; you should always call ttof. Never use char * in writing

code; use LPTSTR. Your version of VS6 has it; it is defined in tchar.h. Note that you need

to install the Unicode libraries; most of the Unicode support did not install by default.

Just go to Add/Remove programs, select Visual Studio, and go into the install wizard and

add various Unicode-based options for libraries and such (while you're at it, install the

C runtime source code as well; it is useful to have around).



Note that you must specify both the UNICODE and _UNICODE preprocessor symbols (one

controls the C library, one controls the WIndows library, and if you don't specify both,

you would get errors like the one you have cited). strstream is part of the standard C++

library, which sucks as far as Unicode support is concerned, since it is still living in

the early days of C++ (and hasn't grown up). I suggest avoiding anything like this. It is

one of the several reaons I avoid the "standard" C++ library. It lives in some weird world

that never heard of Unicode.

joe



On Thu, 8 Jan 2004 14:56:08 -0700, "XL Zhou" <xuelong@pvtprop.com>wrote:



Joseph M. Newcomer [MVP]

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

Not true for other implementations or for the ones in VS.NET 2002 & 2003



So, it is not about C++, is about MS's C++

But I also have to admint they are not so guilty.

At the time VS6 was released, the C++ was not really an approved standard.

Why do I think MS is somewat guilty? Because it did wait for such a long

time before releasing something better.



Mihai

-