|
Hi,
Lei.
Meanwhile I was able to migrate my application
following your hints. It works like a charm, and Hiragana characters entered in
the xml configuration file get displayed on the screen.
Now
the only location where I'd like to have reasonable output is the log file.
Unfortunately, CStdioFile::WriteString() does not write the hiragana characters,
it seems to completely ignore them.
Do you
have any idea how I can obtain an UTF8 encoded log file (not
XML)?
Hiran
Hi, Hiran,
If you're using VC++, it's best to use
CString for portability between ANSI and UNICODE build.
Though the type of CString's internal
storage changes according to the "UNICODE" directive, there are several
macros that can help you to transcode a TCHAR string into an ANSI string
or a UCS2 string. See the code snippet below:
#include <atlvbase.h>
#include<atlconv.h>
......
void myUnicodeFunc(LPCWSTR
lpszUnicodeText);
void myAnsiFunc(LPCSTR
lpszAnsiText);
......
void myfunc(LPCTSTR
lpszMyText)
{
USES_CONVERSION;
myUnicodeFunc(T2W((LPTSTR)lpszMyText));
myAnsiFunc(T2A((LPTSTR)lpszMyText));
}
Definition of these macros will
also change according to the "UNICODE" directive. i.e., if you
compile your code as UNICODE, the T2W macro will be obmitted and the T2A macro
will call a helper function to transcode the unicode string into ANSI. And
vice versa.
There are a lot of other ATL macros
like T2A, A2T, A2W... etc. To use them you need to include 2 header files
and declare the "USES_CONVERSION" macro in your function.
And remember these macros uses temporary
variables, so you can not store the pointer for later use. And it's not
recommended to put them in a loop. Consult your MSDN for more
information.
regards
Lei
----- Original Message -----
Sent: Friday, February 06, 2004 9:25
PM
Subject: RE: MemBufInputSource with
CString
Hi, Alberto.
Makes sense. Will try it when I
get that far. Thank you.
Hiran
> -----Original
Message-----
> From: Alberto Massari
[mailto:amassari@xxxxxxxxxxxx]
> Sent: Friday, February 06, 2004 1:14
PM
> To: xerces-c-dev@xxxxxxxxxxxxxx
> Subject: RE: MemBufInputSource with
CString
>
>
> At 12.36 06/02/2004 +0100, Chaudhuri, Hiran
wrote:
> >Hi, Lei.
> >
> >Having followed this
thread, a question arises for me.
> >I am in a similar situation with
an application that keeps its
> >configuration in an XML file. This
file is also intended to contain
> >localized messages. I thought
that to be a good idea as XML
> should handle
> >Unicode, and
of course I'd compile my VC++ appication with Unicode,
> >expecting
CString to work on 16 bit characters (or whatever
> appropriate)
> >to support Japanese messages.
> >
> >Now how do
I have to use the unicode CString with Xerces? Is there a
>
>suitable XMLString::transcode method?
>
> When the CString is
used with _UNICODE defined, its internal
> storage is the
> same
Xerces uses; so you should just cast it using (LPCTSTR).
>
>
Alberto
>
> >Hiran
> >
> >
> > >
-----Original Message-----
> > > From: jiang lei
[mailto:jiang-lei@xxxxxxxxxx]
> > > Sent: Wednesday, February 04,
2004 9:41 AM
> > > To: xerces-c-dev@xxxxxxxxxxxxxx
> > > Subject: Re: MemBufInputSource with CString
> >
>
> > >
> > > Hi Jimmy,
> > >
>
> > A few suggestions:
> > >
> > > 1.in your
function void X(CString setting, CString changeval) ,
> > >
Passing parameters by object is usually not a good idea.
> > >
Unless, of course
> > > you want to make copies and leave
the masters intact.(
> CString's copy
> > > constructor,
however, will share the master's buffer if the
> > > LPCTSTR()
cast
> > > is not used.)
> > >
> > > 2.
Notice that CString's internal buffer is of type "TCAR"
> > >
rather than the
> > > intrinsic c type "char". It will change into
"wchar_t" if
> > > someone compiles
> > > your program
with a "UNICODE" directive. I'd preffer
> > > std::string in
this
> > > case. But in your program I did not see any necessity
to
> use a string
> > > object. A simple "const char*"
pointer will work just fine.
> > >
> > > 3. AFAIK
XercesDOMParser will delete it's internal
> document in it's
>
> > destructor. So if you delete the parser in ParseDocument(),
the
> > > "DOMDocument"pointer you returned will be invalid and
cause a
> > > protection
> > > fault if you try to use
the object. On the other hand if you
> > > don't delete
>
> > it, there will be a memory leak. So your program can either:
>
> > keep a pointer to the parser when you
use "new" to
> > > create it. Make sure
> > > the
parser lives long enough until you've finished using
> it's
internal
> > > document
object.
and then delete the parser.
> > > or
> >
> make a copy of the parser's internal
document and
> > > delete the parser in
> > >
ParseDocument();
> > >
> > > remember in C++ every
object created with "new" should be
> > > destructed with
>
> > "delete", and it's up to you to keep those objects valid.
>
> >
> > >
> > >
> > >
regards
> > >
> > > Lei
> > >
> >
>
> > >
> > >
>
---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xxxxxxxxxxxxxx
> > > For additional commands, e-mail:
xerces-c-dev-help@xxxxxxxxxxxxxx
> > >
> > >
>
>
>
>---------------------------------------------------------------------
>
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xxxxxxxxxxxxxx
> >For additional commands, e-mail: xerces-c-dev-help@xxxxxxxxxxxxxx
>
>
>
>
---------------------------------------------------------------------
>
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xxxxxxxxxxxxxx
> For additional commands, e-mail: xerces-c-dev-help@xxxxxxxxxxxxxx
>
>
---------------------------------------------------------------------
To
unsubscribe, e-mail: xerces-c-dev-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: xerces-c-dev-help@xxxxxxxxxxxxxx
|
