corrected EVT_NOTIFY[_RANGE] docs (bug 1439078)

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

diff --git a/docs/latex/wx/tstream.tex b/docs/latex/wx/tstream.tex
index 5709db71d80c56e6fdd53933c1176b6b355f1811..7b456062a2fe19749846e64baa30959dd4e14aa6 100644 (file)
--- a/docs/latex/wx/tstream.tex
+++ b/docs/latex/wx/tstream.tex
@@ -1,4 +1,4 @@
-\section{Streams in wxWindows overview}\label{wxstreamoverview}
+\section{wxStreams overview}\label{wxstreamoverview}
 
 Classes: \helpref{wxStreamBase}{wxstreambase},
  \helpref{wxStreamBuffer}{wxstreambuffer}, \helpref{wxInputStream}{wxinputstream},
@@ -8,17 +8,18 @@ Classes: \helpref{wxStreamBase}{wxstreambase},
 
 \wxheading{Purpose of wxStream}
 
-We went into troubles with C++ std streams on several platforms:
-they react quite well in most cases, but in multi-threaded case, for example,
-they have many problems. Some Borland Compilers refuse to work at all
-with them and using iostreams on Linux makes writing programs, that are
+Standard C++ streams can cause problems on several platforms:
+they work quite well in most cases, but in the multi-threaded case, for example,
+they have many problems. Some Borland compilers refuse to work at all
+with them and using iostreams on Linux makes writing programs that are
 binary compatible across different Linux distributions, impossible.
 
-Therefore, wxStreams have been added to wxWindows because an application should 
-compile and run on all supported platforms and we don't want users depend on release
-X.XX of libg++ or some other compiler to run the program.
+Therefore, wxStreams have been added to wxWidgets so that applications can
+reliably compile and run on all supported platforms without dependence on a
+particular release of libg++.
 
 wxStreams is divided in two main parts:
+
 \begin{enumerate}\itemsep=0pt
 \item the core: wxStreamBase, wxStreamBuffer, wxInputStream, wxOutputStream,
 wxFilterIn/OutputStream
@@ -26,20 +27,20 @@ wxFilterIn/OutputStream
 \end{enumerate}
 
 wxStreamBase is the base definition of a stream. It defines, for example,
-the API of OnSysRead, OnSysWrite, OnSysSeek and OnSysTell. These functions are
+the API of OnSysRead, OnSysWrite, OnSysSeek and OnSysTell. These functions 
 are really implemented by the "IO" classes.
 wxInputStream and wxOutputStream inherit from it.
 
-wxStreamBuffer is a cache manager for wxStreamBase (it manages a stream buffer
-linked to a stream). One stream can have multiple stream buffers  but one stream
+wxStreamBuffer is a cache manager for wxStreamBase: it manages a stream buffer
+linked to a stream. One stream can have multiple stream buffers  but one stream
 have always one autoinitialized stream buffer.
 
 wxInputStream is the base class for read-only streams. It implements Read,
 SeekI (I for Input), and all read or IO generic related functions.
 wxOutputStream does the same thing but it is for write-only streams.
 
-wxFilterIn/OutputStream is base class definition for stream filtering.
-I mean by stream filtering, a stream which does no syscall but filter datas
+wxFilterIn/OutputStream is the base class definition for stream filtering.
+Stream filtering means a stream which does no syscall but filters data
 which are passed to it and then pass them to another stream.
 For example, wxZLibInputStream is an inline stream decompressor.
 
@@ -50,7 +51,7 @@ wxStreamBuffer. This could also be a simple link to the a true syscall
 
 \wxheading{Generic usage: an example}
 
-About its usage, it's simple. We can take the example of wxFileInputStream and here is a sample
+Usage is simple. We can take the example of wxFileInputStream and here is some sample
 code:
 
 \begin{verbatim}
@@ -61,13 +62,13 @@ code:
 
  // Ok, read some bytes ... nb_datas is expressed in bytes.
  in_stream.Read(data, nb_datas);
- if (in_stream.LastError() != wxStream_NOERROR) {
+ if (in_stream.LastError() != wxSTREAM_NOERROR) {
    // Oh oh, something bad happens.
    // For a complete list, look into the documentation at wxStreamBase.
  }
 
  // You can also inline all like this.
- if (in_stream.Read(data, nb_datas).LastError() != wxStream_NOERROR) {
+ if (in_stream.Read(data, nb_datas).LastError() != wxSTREAM_NOERROR) {
    // Do something.
  }
 
@@ -81,12 +82,6 @@ code:
  // What is my current position ?
  off_t position = in_stream.TellI();
 
- // wxFileInputStream will close the file descriptor on the destruction.
+ // wxFileInputStream will close the file descriptor on destruction.
 \end{verbatim}
 
-\wxheading{Compatibility with c++ stream}
-
-As I said previously, we could add a filter stream so it takes an istream
-argument and builds a wxInputStream from it: I don't think it should 
-be difficult to implement it and it may be available in the fix of wxWindows 2.0.
-