wxMGL bugfixes

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

diff --git a/docs/latex/wx/porting.tex b/docs/latex/wx/porting.tex
index 306260b397e1ea82cd0858d556f87781a27c9b0c..14aac3ca3b61cf5f35daf286eabbb0ab62addf51 100644 (file)
--- 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
 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.}
 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:
 
 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)
 {
         ...
 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
 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...
 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
 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
 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


@@ -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:
 
 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();
   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}
   .... // 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:
 
 
 with this:
 

-{\small\begin{verbatim}
+{\small
+\begin{verbatim}

   wxString s = wxFunctionThatReturnsString();
   .... // Do something with it
 \end{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
 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}
 
 
 \subsection{OnEvent}