fixed assert in SetItemText() for wxTR_MULTIPLE controls

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

diff --git a/docs/latex/wx/tapp.tex b/docs/latex/wx/tapp.tex
index 9deac1d1bacc1810272d84271753a6f1d79ed200..3b33252eff1517754cf02ca02c18ce6458fa1bac 100644 (file)
--- a/docs/latex/wx/tapp.tex
+++ b/docs/latex/wx/tapp.tex
@@ -2,13 +2,13 @@
 
 Classes: \helpref{wxApp}{wxapp}
 
 
 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.
 
 \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
-returns a boolean value which indicates whether processing should continue (TRUE) or not (FALSE).
-You call \helpref{wxApp::SetTopWindow}{wxappsettopwindow} to let wxWindows know
+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 wxWidgets know

 about the top window.
 
 Note that the program's command line arguments, represented by {\it argc} 
 about the top window.
 
 Note that the program's command line arguments, represented by {\it argc} 


@@ -40,21 +40,23 @@ bool DerivedApp::OnInit()
 {
   wxFrame *the_frame = new wxFrame(NULL, ID_MYFRAME, argv[0]);
   ...
 {
   wxFrame *the_frame = new wxFrame(NULL, ID_MYFRAME, argv[0]);
   ...

-  the_frame->Show(TRUE);
+  the_frame->Show(true);

   SetTopWindow(the_frame);
 
   SetTopWindow(the_frame);
 

-  return TRUE;
+  return true;

 }
 \end{verbatim}
 
 }
 \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.
 
 You can also use DECLARE\_APP(appClass) in a header file to declare the wxGetApp function which returns
 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.
 
 You can also use DECLARE\_APP(appClass) in a header file to declare the wxGetApp function which returns

-a reference to the application object.
+a reference to the application object. Otherwise you can only use the global 
+\texttt{wxTheApp} pointer which is of type \texttt{wxApp *}.
+

 
 \subsection{Application shutdown}\label{wxappshutdownoverview}
 
 
 \subsection{Application shutdown}\label{wxappshutdownoverview}
 


@@ -63,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
 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
 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


@@ -72,8 +74,8 @@ moment -- is closed.
 
 
 Another aspect of the application shutdown is the \helpref{OnExit}{wxapponexit} 
 
 
 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!
 
 created by the time OnExit finishes. In particular, do {\bf not} destroy them
 from application class' destructor!
 


@@ -90,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 
 
 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}
 uninitialized! The solution is to destroy HelpCtrl in {\it OnExit}:
 
 \begin{verbatim}