documented wxCONCAT

[wxWidgets.git] / docs / latex / wx / tunicode.tex

diff --git a/docs/latex/wx/tunicode.tex b/docs/latex/wx/tunicode.tex
index 693edee8e5698f645fd276eef2ee42fb4f24a6df..aa491e32421d0c5e229a03d1d2754ed20636dfaf 100644 (file)
--- a/docs/latex/wx/tunicode.tex
+++ b/docs/latex/wx/tunicode.tex
@@ -130,25 +130,25 @@ a separate type for strings though, because the standard
 \helpref{wxString}{wxstring} supports Unicode, i.e. it stores either ANSI or
 Unicode strings depending on the compile mode.
 
 \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
 
 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}
 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}
 
 \item Use {\tt wxString} instead of C style strings.
 \end{itemize}
 


@@ -160,7 +160,7 @@ Although everything works fine inside the program, things can get nasty when
 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
 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
 
 To get a ANSI string from a wxString, you may use the 
 mb\_str() function which always returns an ANSI


@@ -175,13 +175,14 @@ the Unicode string.
 \subsection{Unicode-related compilation settings}
 
 You should define {\tt wxUSE\_UNICODE} to $1$ to compile your program in
 \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
 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).
 
 from some external file or elsewhere).