Name change replacements

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@27090 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Julian Smart
2004-05-04 08:27:20 +00:00
parent e119d0498a
commit fc2171bd4c
268 changed files with 1372 additions and 1366 deletions

View File

@@ -1,12 +1,12 @@
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Name: tmbconv.tex
%% Purpose: Overview of the wxMBConv classes in wxWindows
%% Purpose: Overview of the wxMBConv classes in wxWidgets
%% Author: Ove Kaaven
%% Modified by:
%% Created: 25.03.00
%% RCS-ID: $Id$
%% Copyright: (c) 2000 Ove Kaaven
%% Licence: wxWindows license
%% Licence: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{wxMBConv classes overview}\label{mbconvclasses}
@@ -16,7 +16,7 @@ Classes: \helpref{wxMBConv}{wxmbconv}, wxMBConvLibc,
\helpref{wxCSConv}{wxcsconv},
\helpref{wxMBConvUTF16}{wxmbconvutf16}, \helpref{wxMBConvUTF32}{wxmbconvutf32}
The wxMBConv classes in wxWindows enables an Unicode-aware application to
The wxMBConv classes in wxWidgets enables an Unicode-aware application to
easily convert between Unicode and the variety of 8-bit encoding systems still
in use.
@@ -42,7 +42,7 @@ pass unhindered through any traditional transport channels.
\subsection{Background: The wxString class}
If you have compiled wxWindows in Unicode mode, the wxChar type will become
If you have compiled wxWidgets in Unicode mode, the wxChar type will become
identical to wchar\_t rather than char, and a wxString stores wxChars. Hence,
all wxString manipulation in your application will then operate on Unicode
strings, and almost as easily as working with ordinary char strings (you
@@ -65,7 +65,7 @@ is override the MB2WC and WC2MB methods.
\subsection{wxMBConv objects}
Several of the wxWindows-provided wxMBConv classes have predefined instances
Several of the wxWidgets-provided wxMBConv classes have predefined instances
(wxConvLibc, wxConvFile, wxConvUTF7, wxConvUTF8, wxConvLocal). You can use
these predefined objects directly, or you can instantiate your own objects.
@@ -89,7 +89,7 @@ it is better to go through wxConvCurrent.
Once you have chosen which object you want to use to convert your text,
here is how you would use them with wxString. These examples all assume
that you are using a Unicode build of wxWindows, although they will still
that you are using a Unicode build of wxWidgets, although they will still
compile in a non-Unicode build (they just won't convert anything).
Example 1: Constructing a wxString from input in current encoding.
@@ -133,7 +133,7 @@ it in a vararg context (like with printf).
If you have specialized needs, or just don't want to use wxString, you
can also use the conversion methods of the conversion objects directly.
This can even be useful if you need to do conversion in a non-Unicode
build of wxWindows; converting a string from UTF-8 to the current
build of wxWidgets; converting a string from UTF-8 to the current
encoding should be possible by doing this:
\begin{verbatim}
@@ -143,7 +143,7 @@ wxString str(wxConvUTF8.cMB2WC(input_data), *wxConvCurrent);
Here, cMB2WC of the UTF8 object returns a wxWCharBuffer containing a Unicode
string. The wxString constructor then converts it back to an 8-bit character
set using the passed conversion object, *wxConvCurrent. (In a Unicode build
of wxWindows, the constructor ignores the passed conversion object and
of wxWidgets, the constructor ignores the passed conversion object and
retains the Unicode data.)
This could also be done by first making a wxString of the original data: