rolled back exceptions handling patch, it relied on incorrect assumption about vtables

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

diff --git a/docs/latex/wx/wxstring.tex b/docs/latex/wx/wxstring.tex
index 536e2abfec88bec00a5b424557f12af2a2e347ef..83e38962507bdff25614d374a600e55dbff31559 100644 (file)
--- a/docs/latex/wx/wxstring.tex
+++ b/docs/latex/wx/wxstring.tex
@@ -1257,7 +1257,7 @@ buffer (which must be writable, of course) you might call it like this:
 \end{verbatim}
 
 Note that the exact usage of this depends on whether on not wxUSE\_STL is enabled.  If
-wxUSE\_STL is enabled, wxStringBuffer creates a seperate empty character buffer, and
+wxUSE\_STL is enabled, wxStringBuffer creates a separate empty character buffer, and
 if wxUSE\_STL is disabled, it uses GetWriteBuf() from wxString, keeping the same buffer
 wxString uses intact.  In other words, relying on wxStringBuffer containing the old 
 wxString data is probably not a good idea if you want to build your program in both
@@ -1322,7 +1322,7 @@ of the string, you might call it like this:
 \end{verbatim}
 
 Note that the exact usage of this depends on whether on not wxUSE\_STL is enabled.  If
-wxUSE\_STL is enabled, wxStringBuffer creates a seperate empty character buffer, and
+wxUSE\_STL is enabled, wxStringBuffer creates a separate empty character buffer, and
 if wxUSE\_STL is disabled, it uses GetWriteBuf() from wxString, keeping the same buffer
 wxString uses intact.  In other words, relying on wxStringBuffer containing the old 
 wxString data is probably not a good idea if you want to build your program in both