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

@@ -2,7 +2,7 @@
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}
The functions and macros defined in wxWindows are described here: you can
The functions and macros defined in wxWidgets are described here: you can
either look up a function using the alphabetical listing of them or find it in
the corresponding topic.
@@ -244,21 +244,21 @@ the corresponding topic.
\section{Version macros}\label{versionfunctions}
The following constants are defined in wxWindows:
The following constants are defined in wxWidgets:
\begin{itemize}\itemsep=0pt
\item {\tt wxMAJOR\_VERSION} is the major version of wxWindows
\item {\tt wxMINOR\_VERSION} is the minor version of wxWindows
\item {\tt wxMAJOR\_VERSION} is the major version of wxWidgets
\item {\tt wxMINOR\_VERSION} is the minor version of wxWidgets
\item {\tt wxRELEASE\_NUMBER} is the release number
\end{itemize}
For example, the values or these constants for wxWindows 2.1.15 are 2, 1 and
For example, the values or these constants for wxWidgets 2.1.15 are 2, 1 and
15.
Additionally, {\tt wxVERSION\_STRING} is a user-readable string containing
the full wxWindows version and {\tt wxVERSION\_NUMBER} is a combination of the
the full wxWidgets version and {\tt wxVERSION\_NUMBER} is a combination of the
three version numbers above: for 2.1.15, it is 2115 and it is 2200 for
wxWindows 2.2.
wxWidgets 2.2.
\wxheading{Include files}
@@ -269,10 +269,10 @@ wxWindows 2.2.
\func{bool}{wxCHECK\_VERSION}{\param{}{major, minor, release}}
This is a macro which evaluates to true if the current wxWindows version is at
This is a macro which evaluates to true if the current wxWidgets version is at
least major.minor.release.
For example, to test if the program is compiled with wxWindows 2.2 or higher,
For example, to test if the program is compiled with wxWidgets 2.2 or higher,
the following can be done:
\begin{verbatim}
@@ -315,31 +315,31 @@ to control the behaviour of the main event loop of the GUI programs.
\membersection{::wxEntry}\label{wxentry}
This initializes wxWindows in a platform-dependent way. Use this if you
are not using the default wxWindows entry code (e.g. main or WinMain). For example,
you can initialize wxWindows from an Microsoft Foundation Classes application using
This initializes wxWidgets in a platform-dependent way. Use this if you
are not using the default wxWidgets entry code (e.g. main or WinMain). For example,
you can initialize wxWidgets from an Microsoft Foundation Classes application using
this function.
\func{void}{wxEntry}{\param{HANDLE}{ hInstance}, \param{HANDLE}{ hPrevInstance},
\param{const wxString\& }{commandLine}, \param{int}{ cmdShow}, \param{bool}{ enterLoop = true}}
wxWindows initialization under Windows (non-DLL). If {\it enterLoop} is false, the
function will return immediately after calling wxApp::OnInit. Otherwise, the wxWindows
wxWidgets initialization under Windows (non-DLL). If {\it enterLoop} is false, the
function will return immediately after calling wxApp::OnInit. Otherwise, the wxWidgets
message loop will be entered.
\func{void}{wxEntry}{\param{HANDLE}{ hInstance}, \param{HANDLE}{ hPrevInstance},
\param{WORD}{ wDataSegment}, \param{WORD}{ wHeapSize}, \param{const wxString\& }{ commandLine}}
wxWindows initialization under Windows (for applications constructed as a DLL).
wxWidgets initialization under Windows (for applications constructed as a DLL).
\func{int}{wxEntry}{\param{int}{ argc}, \param{const wxString\& *}{argv}}
wxWindows initialization under Unix.
wxWidgets initialization under Unix.
\wxheading{Remarks}
To clean up wxWindows, call wxApp::OnExit followed by the static function
wxApp::CleanUp. For example, if exiting from an MFC application that also uses wxWindows:
To clean up wxWidgets, call wxApp::OnExit followed by the static function
wxApp::CleanUp. For example, if exiting from an MFC application that also uses wxWidgets:
\begin{verbatim}
int CTheApp::ExitInstance()
@@ -362,7 +362,7 @@ int CTheApp::ExitInstance()
\func{wxAppDerivedClass\&}{wxGetApp}{\void}
This function doesn't exist in wxWindows but it is created by using
This function doesn't exist in wxWidgets but it is created by using
the \helpref{IMPLEMENT\_APP}{implementapp} macro. Thus, before using it
anywhere but in the same module where this macro is used, you must make it
available using \helpref{DECLARE\_APP}{declareapp}.
@@ -408,7 +408,7 @@ see \helpref{wxImage}{wximage}.
This function is used in wxBase only and only if you don't create
\helpref{wxApp}{wxapp} object at all. In this case you must call it from your
{\tt main()} function before calling any other wxWindows functions.
{\tt main()} function before calling any other wxWidgets functions.
If the function returns {\tt false} the initialization could not be performed,
in this case the library cannot be used and
@@ -974,7 +974,7 @@ directory doesn't exist).
This function is implemented for Win32,
Mac OS and generic Unix provided the system has {\tt statfs()} function.
This function first appeared in wxWindows 2.3.2.
This function first appeared in wxWidgets 2.3.2.
\membersection{::wxGetOSDirectory}\label{wxgetosdirectory}
@@ -1251,7 +1251,7 @@ the domain name.
Under Windows or NT, this function first looks in the environment
variable SYSTEM\_NAME; if this is not found, the entry {\bf HostName}\rtfsp
in the {\bf wxWindows} section of the WIN.INI file is tried.
in the {\bf wxWidgets} section of the WIN.INI file is tried.
The first variant of this function returns the hostname if successful or an
empty string otherwise. The second (deprecated) function returns true
@@ -1277,7 +1277,7 @@ something like "jsmith". It uniquely identifies the current user (on this system
Under Windows or NT, this function first looks in the environment
variables USER and LOGNAME; if neither of these is found, the entry {\bf UserId}\rtfsp
in the {\bf wxWindows} section of the WIN.INI file is tried.
in the {\bf wxWidgets} section of the WIN.INI file is tried.
The first variant of this function returns the login name if successful or an
empty string otherwise. The second (deprecated) function returns true
@@ -1362,7 +1362,7 @@ Returns the home directory for the given user. If the username is empty
This function returns the full user name (something like "Mr. John Smith").
Under Windows or NT, this function looks for the entry {\bf UserName}\rtfsp
in the {\bf wxWindows} section of the WIN.INI file. If PenWindows
in the {\bf wxWidgets} section of the WIN.INI file. If PenWindows
is running, the entry {\bf Current} in the section {\bf User} of
the PENWIN.INI file is used.
@@ -1623,7 +1623,7 @@ Don't confuse this macro with \helpref{\_T()}{underscoret}!
\func{const wxChar *}{\_T}{\param{const wxChar }{ch}}
This macro is exactly the same as \helpref{wxT}{wxt} and is defined in
wxWindows simply because it may be more intuitive for Windows programmers as
wxWidgets simply because it may be more intuitive for Windows programmers as
the standard Win32 headers also define it (as well as yet another name for the
same macro which is {\tt \_TEXT()}).
@@ -2276,7 +2276,7 @@ the equivalent of the following code to the start of the metafile data:
SetWindowExt(dc, maxX - minX, maxY - minY);
\end{verbatim}
This simulates the wxMM\_TEXT mapping mode, which wxWindows assumes.
This simulates the wxMM\_TEXT mapping mode, which wxWidgets assumes.
Placeable metafiles may be imported by many Windows applications, and can be
used in RTF (Rich Text Format) files.
@@ -2655,7 +2655,7 @@ the given {\bf id}.
\func{void}{wxDDECleanUp}{\void}
Called when wxWindows exits, to clean up the DDE system. This no longer needs to be
Called when wxWidgets exits, to clean up the DDE system. This no longer needs to be
called by the application.
See also \helpref{wxDDEInitialize}{wxddeinitialize}.
@@ -2672,7 +2672,7 @@ See also \helpref{wxDDEInitialize}{wxddeinitialize}.
Initializes the DDE system. May be called multiple times without harm.
This no longer needs to be called by the application: it will be called
by wxWindows if necessary.
by wxWidgets if necessary.
See also \helpref{wxDDEServer}{wxddeserver}, \helpref{wxDDEClient}{wxddeclient}, \helpref{wxDDEConnection}{wxddeconnection},\rtfsp
\helpref{wxDDECleanUp}{wxddecleanup}.
@@ -3046,7 +3046,7 @@ data in big-endian format.
\section{RTTI functions}\label{rttimacros}
wxWindows uses its own RTTI ("run-time type identification") system which
wxWidgets uses its own RTTI ("run-time type identification") system which
predates the current standard C++ RTTI and so is kept for backwards
compatibility reasons but also because it allows some things which the
standard RTTI doesn't directly support (such as creating a class from its
@@ -3054,7 +3054,7 @@ name).
The standard C++ RTTI can be used in the user code without any problems and in
general you shouldn't need to use the functions and the macros in this section
unless you are thinking of modifying or adding any wxWindows classes.
unless you are thinking of modifying or adding any wxWidgets classes.
\wxheading{See also}
@@ -3198,7 +3198,7 @@ a class that has run-time type information and two base classes. The same as IMP
\func{}{IMPLEMENT\_APP}{className}
This is used in the application class implementation file to make the application class known to
wxWindows for dynamic construction. You use this instead of
wxWidgets for dynamic construction. You use this instead of
Old form:
@@ -3421,7 +3421,7 @@ star is not appended to it.
These functions provide a variety of logging functions: see \helpref{Log classes overview}{wxlogoverview} for
further information. The functions use (implicitly) the currently active log
target, so their descriptions here may not apply if the log target is not the
standard one (installed by wxWindows in the beginning of the program).
standard one (installed by wxWidgets in the beginning of the program).
\wxheading{Include files}
@@ -3455,14 +3455,14 @@ instead.
\membersection{::wxError}\label{wxerror}
\func{void}{wxError}{\param{const wxString\& }{msg}, \param{const wxString\& }{title = "wxWindows Internal Error"}}
\func{void}{wxError}{\param{const wxString\& }{msg}, \param{const wxString\& }{title = "wxWidgets Internal Error"}}
{\bf NB:} This function is now obsolete, please use \helpref{wxLogError}{wxlogerror}
instead.
Displays {\it msg} and continues. This writes to standard error under
Unix, and pops up a message box under Windows. Used for internal
wxWindows errors. See also \helpref{wxFatalError}{wxfatalerror}.
wxWidgets errors. See also \helpref{wxFatalError}{wxfatalerror}.
\wxheading{Include files}
@@ -3471,14 +3471,14 @@ wxWindows errors. See also \helpref{wxFatalError}{wxfatalerror}.
\membersection{::wxFatalError}\label{wxfatalerror}
\func{void}{wxFatalError}{\param{const wxString\& }{msg}, \param{const wxString\& }{title = "wxWindows Fatal Error"}}
\func{void}{wxFatalError}{\param{const wxString\& }{msg}, \param{const wxString\& }{title = "wxWidgets Fatal Error"}}
{\bf NB:} This function is now obsolete, please use
\helpref{wxLogFatalError}{wxlogfatalerror} instead.
Displays {\it msg} and exits. This writes to standard error under Unix,
and pops up a message box under Windows. Used for fatal internal
wxWindows errors. See also \helpref{wxError}{wxerror}.
wxWidgets errors. See also \helpref{wxError}{wxerror}.
\wxheading{Include files}
@@ -3564,7 +3564,7 @@ If the target frame doesn't have a statusbar, the message will be lost.
\func{void}{wxVLogSysError}{\param{const char *}{formatString}, \param{va\_list }{argPtr}}
Mostly used by wxWindows itself, but might be handy for logging errors after
Mostly used by wxWidgets itself, but might be handy for logging errors after
system call (API function) failure. It logs the specified message text as well
as the last system error code ({\it errno} or {\it ::GetLastError()} depending
on the platform) and the corresponding error message. The second form
@@ -3617,7 +3617,7 @@ the mask has been previously enabled by the call to
\helpref{AddTraceMask}{wxlogaddtracemask} or by setting
\helpref{{\tt WXTRACE} environment variable}{envvars}.
The predefined string trace masks
used by wxWindows are:
used by wxWidgets are:
\begin{itemize}\itemsep=0pt
\item wxTRACE\_MemAlloc: trace memory allocation (new/delete)
@@ -3889,7 +3889,7 @@ standard usleep() function is not MT safe.
\section{Debugging macros and functions}\label{debugmacros}
Useful macros and functions for error checking and defensive programming.
wxWindows defines three families of the assert-like macros:
wxWidgets defines three families of the assert-like macros:
the wxASSERT and wxFAIL macros only do anything if \_\_WXDEBUG\_\_ is defined
(in other words, in the debug build) but disappear completely in the release
build. On the other hand, the wxCHECK macros stay event in release builds but a