X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/5eae411929abf27882cb9da8e20ef3b81664debd..56b88f1276ea4049a21f6174842b56ca9f280a3f:/docs/latex/wx/porting.tex

diff --git a/docs/latex/wx/porting.tex b/docs/latex/wx/porting.tex
index 306260b397..bc15b659c2 100644
--- a/docs/latex/wx/porting.tex
+++ b/docs/latex/wx/porting.tex
@@ -18,7 +18,7 @@ and will be supported by the user community for some time. And when you have
 changed to 2.0, we hope that you will appreciate the benefits in terms
 of greater flexibility, better user interface aesthetics, improved C++ conformance,
 improved compilation speed, and many other enhancements. The revised architecture
-of 2.0 will ensure that wxWindows can continue to evolve for the forseeable
+of 2.0 will ensure that wxWindows can continue to evolve for the foreseeable
 future.
 
 {\it Please note that this document is a work in progress.}
@@ -57,7 +57,8 @@ for some notes on using member functions for callbacks. wxWindows 2.0 will banis
 callback functions (and OnMenuCommand), and nearly all event handling will be done by functions taking a single event argument.
 So in future you will have code like:
 
-{\small\begin{verbatim}
+{\small
+\begin{verbatim}
 void MyFrame::OnOK(wxCommandEvent& event)
 {
         ...
@@ -75,7 +76,7 @@ be no conversion problems later on.
 font sizes (for example, a 12-point font will appear bigger than before). Write your application
 to be flexible where fonts are concerned.
 Don't rely on fonts being similarly-sized across platforms, as they were (by chance) between
-Windows and X under wxWindows 1.66. Yes, this is not easy... but I think it's better to conform to the
+Windows and X under wxWindows 1.66. Yes, this is not easy... but I think it is better to conform to the
 standards of each platform, and currently the size difference makes it difficult to
 conform to Windows UI standards. You may eventually wish to build in a global 'fudge-factor' to compensate
 for size differences. The old font sizing will still be available via wx\_setup.h, so do not panic...
@@ -147,7 +148,7 @@ See \helpref{Device contexts and painting}{portingdc}.
 These objects - instances of classes such as wxPen, wxBrush, wxBitmap (but not wxColour) -
 are now implemented with reference-counting. This makes assignment a very cheap operation,
 and also means that management of the resource is largely automatic. You now pass {\it references} to
-objects to functions such as wxDC::SetPen, not pointers, so you will need to derefence your pointers.
+objects to functions such as wxDC::SetPen, not pointers, so you will need to dereference your pointers.
 The device context does not store a copy of the pen
 itself, but takes a copy of it (via reference counting), and the object's data gets freed up
 when the reference count goes to zero. The application does not have to worry so much about
@@ -188,7 +189,7 @@ is now {\bf wxDialog:ShowModal}. This is part of a more fundamental change in wh
 control may tell the dialog that it caused the dismissal of a dialog, by
 calling {\bf wxDialog::EndModal} or {\bf wxWindow::SetReturnCode}. Using this
 information, {\bf ShowModal} now returns the id of the control that caused dismissal,
-giving greater feedback to the application than just TRUE or FALSE.
+giving greater feedback to the application than just true or false.
 
 If you overrode or called {\bf wxDialog::Show}, use {\bf ShowModal} and test for a returned identifier,
 commonly wxID\_OK or wxID\_CANCEL.
@@ -258,9 +259,10 @@ returned in wxWindows 1.xx, your application will need to be changed. Usually yo
 simplify your application's allocation and deallocation of memory for the returned string,
 and simply assign the result to a wxString object. For example, replace this:
 
-{\small\begin{verbatim}
+{\small
+\begin{verbatim}
   char* s = wxFunctionThatReturnsString();
-  s = copystring(s); // Take a copy in case it's temporary
+  s = copystring(s); // Take a copy in case it is temporary
   .... // Do something with it
   delete[] s;
 \end{verbatim}
@@ -268,7 +270,8 @@ and simply assign the result to a wxString object. For example, replace this:
 
 with this:
 
-{\small\begin{verbatim}
+{\small
+\begin{verbatim}
   wxString s = wxFunctionThatReturnsString();
   .... // Do something with it
 \end{verbatim}
@@ -362,7 +365,7 @@ Add an OnCloseWindow event handler using an EVT\_CLOSE event table entry. For de
 about window destruction, see the Windows Deletion Overview in the manual. This is a subtle
 topic so please read it very carefully. Basically, OnCloseWindow is now responsible for
 destroying a window with Destroy(), but the default implementation (for example for wxDialog) may not
-destroy the window, so to be sure, always provide this event handler so it's obvious what's going on.
+destroy the window, so to be sure, always provide this event handler so it is obvious what's going on.
 
 \subsection{OnEvent}