Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Name change replacements

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/latex/wx/tapp.tex
View File

@@ -2,13 +2,13 @@
Classes: \helpref{wxApp}{wxapp}
A wxWindows application does not have a {\it main} procedure; the equivalent is the
A wxWidgets application does not have a {\it main} procedure; the equivalent is the
\rtfsp\helpref{OnInit}{wxapponinit} member defined for a class derived from wxApp.\rtfsp
\rtfsp{\it OnInit} will usually create a top window as a bare minimum.
Unlike in earlier versions of wxWindows, OnInit does not return a frame. Instead it
Unlike in earlier versions of wxWidgets, OnInit does not return a frame. Instead it
returns a boolean value which indicates whether processing should continue (true) or not (false).
You call \helpref{wxApp::SetTopWindow}{wxappsettopwindow} to let wxWindows know
You call \helpref{wxApp::SetTopWindow}{wxappsettopwindow} to let wxWidgets know
about the top window.
Note that the program's command line arguments, represented by {\it argc}
@@ -47,8 +47,8 @@ bool DerivedApp::OnInit()
}
\end{verbatim}
Note the use of IMPLEMENT\_APP(appClass), which allows wxWindows to dynamically create an instance of the application object
at the appropriate point in wxWindows initialization. Previous versions of wxWindows used
Note the use of IMPLEMENT\_APP(appClass), which allows wxWidgets to dynamically create an instance of the application object
at the appropriate point in wxWidgets initialization. Previous versions of wxWidgets used
to rely on the creation of a global application object, but this is no longer recommended,
because required global initialization may not have been performed at application object
construction time.
@@ -65,7 +65,7 @@ closed. This is normally the expected behaviour and means that it is enough to
call \helpref{Close()}{wxwindowclose} in response to the {\tt "Exit"} menu
command if your program has a single top level window. If this behaviour is not
desirable \helpref{wxApp::SetExitOnFrameDelete}{wxappsetexitonframedelete} can
be called to change it. Note that starting from wxWindows 2.3.3 such logic
be called to change it. Note that starting from wxWidgets 2.3.3 such logic
doesn't apply for the windows shown before the program enters the main loop: in
other words, you can safely show a dialog from
\helpref{wxApp::OnInit}{wxapponinit} and not be afraid that your application
@@ -74,8 +74,8 @@ moment -- is closed.
Another aspect of the application shutdown is the \helpref{OnExit}{wxapponexit}
which is called when the application exits but {\it before} wxWindows cleans up
its internal structures. Your should delete all wxWindows object that your
which is called when the application exits but {\it before} wxWidgets cleans up
its internal structures. Your should delete all wxWidgets object that your
created by the time OnExit finishes. In particular, do {\bf not} destroy them
from application class' destructor!
@@ -92,7 +92,7 @@ class MyApp : public wxApp
The reason for that is that {\tt m\_helpCtrl} is a member object and is
thus destroyed from MyApp destructor. But MyApp object is deleted after
wxWindows structures that wxCHMHelpController depends on were
wxWidgets structures that wxCHMHelpController depends on were
uninitialized! The solution is to destroy HelpCtrl in {\it OnExit}:
\begin{verbatim}