\helpref{wxString}{wxstring} supports Unicode, i.e. it stores either ANSI or
Unicode strings depending on the compile mode.
-Finally, there is a special {\tt wxT()} macro which should enclose all literal
-strings in the program. As it is easy to see comparing the last fragment with
-the one above, this macro expands to nothing in the (usual) ANSI mode and
-prefixes {\tt 'L'} to its argument in the Unicode mode.
+Finally, there is a special \helpref{wxT()}{wxt} macro which should enclose all
+literal strings in the program. As it is easy to see comparing the last
+fragment with the one above, this macro expands to nothing in the (usual) ANSI
+mode and prefixes {\tt 'L'} to its argument in the Unicode mode.
The important conclusion is that if you use {\tt wxChar} instead of
{\tt char}, avoid using C style strings and use {\tt wxString} instead and
-don't forget to enclose all string literals inside {\tt wxT()} macro, your
+don't forget to enclose all string literals inside \helpref{wxT()}{wxt} macro, your
program automatically becomes (almost) Unicode compliant!
Just let us state once again the rules:
\begin{itemize}
\item Always use {\tt wxChar} instead of {\tt char}
-\item Always enclose literal string constants in {\tt wxT()} macro unless
-they're already converted to the right representation (another standard
-wxWindows macro {\tt \_()} does it, so there is no need for {\tt wxT()} in this
-case) or you intend to pass the constant directly to an external function
-which doesn't accept wide-character strings.
+\item Always enclose literal string constants in \helpref{wxT()}{wxt} macro
+unless they're already converted to the right representation (another standard
+wxWindows macro \helpref{\_()}{underscore} does it, for example, so there is no
+need for {\tt wxT()} in this case) or you intend to pass the constant directly
+to an external function which doesn't accept wide-character strings.
\item Use {\tt wxString} instead of C style strings.
\end{itemize}
it tries to communicate with the outside world which, sadly, often expects
ANSI strings (a notable exception is the entire Win32 API which accepts either
Unicode or ANSI strings and which thus makes it unnecessary to ever perform
-any conversions in the program).
+any conversions in the program). GTK 2.0 only accepts UTF-8 strings.
To get a ANSI string from a wxString, you may use the
mb\_str() function which always returns an ANSI
\subsection{Unicode-related compilation settings}
You should define {\tt wxUSE\_UNICODE} to $1$ to compile your program in
-Unicode mode. Note that it currently only works in Win32 and that some parts of
+Unicode mode. Note that it currently only works in Win32 and GTK 2.0 and
+that some parts of
wxWindows are not Unicode-compliant yet (ODBC classes, for example). If you
compile your program in ANSI mode you can still define {\tt wxUSE\_WCHAR\_T}
to get some limited support for {\tt wchar\_t} type.
This will allow your program to perform conversions between Unicode strings and
-ANSI ones (\helpref{wxEncodingConverter}{wxencodingconverter} depends on this
-partially) and construct wxString objects from Unicode strings (presumably read
+ANSI ones (using \helpref{wxMBConv classes}{mbconvclasses})
+and construct wxString objects from Unicode strings (presumably read
from some external file or elsewhere).