Merge branch 'bsmr-erlang/fix_wx_typos' into maint

* bsmr-erlang/fix_wx_typos:
  fix documentation

OTP-11505

1 files changed, 21 insertions, 21 deletions

diff --git a/lib/wx/doc/overview.edoc b/lib/wx/doc/overview.edoc
index 8bff6c34e1..054016f515 100644
--- a/lib/wx/doc/overview.edoc
+++ b/lib/wx/doc/overview.edoc
@@ -12,11 +12,11 @@ of <em>wxWidgets</em>. This document describes the erlang mapping to
 wxWidgets and it's implementation. It is not a complete
 users guide to wxWidgets. If you need that, you will have to read the wxWidgets
 documentation instead. <em>wx</em> tries to keep a one-to-one mapping with
-the original api so that the original documentation and examples shall be
+the original API so that the original documentation and examples shall be
 as easy as possible to use.
 
 wxErlang examples and test suite can be found in the erlang src release.
-They can also provide some help on how to use the api.
+They can also provide some help on how to use the API.
 
 This is currently a very brief introduction to <em>wx</em>.  The
 application is still under development, which means the interface may change,
@@ -33,17 +33,17 @@ and the test suite currently have a poor coverage ratio.
 
 == Introduction == 
 
-The original <em>wxWidgets</em> is an object-oriented (C++) api and
+The original <em>wxWidgets</em> is an object-oriented (C++) API and
 that is reflected in the erlang mapping. In most cases each class in
 wxWidgets is represented as a module in erlang. This gives
 the <em>wx</em> application a huge interface, spread over several
 modules, and it all starts with the <em>wx</em>
 module. The <em>wx</em> module contains functions to create and
-destroy the gui, i.e. <code>wx:new/0</code>,<code>wx:destroy/0</code>, and
+destroy the GUI, i.e. <code>wx:new/0</code>, <code>wx:destroy/0</code>, and
 some other useful functions. 
 
 Objects or object references in <em>wx</em> should be seen as erlang
-processes rather then erlang terms. When you operate on them they can
+processes rather than erlang terms. When you operate on them they can
 change state, e.g. they are not functional objects as erlang terms are.
 Each object has a type or rather a class, which is manipulated with
 the corresponding module or by sub-classes of that object. Type
@@ -62,7 +62,7 @@ For example the <em>wxWindow</em> C++ class is implemented in the
 member <em>wxWindow::CenterOnParent</em> is
 thus <em>wxWindow:centerOnParent</em>.  The following C++ code:
 <pre>
-  wxWindow MyWin = new wxWindo();
+  wxWindow MyWin = new wxWindow();
   MyWin.CenterOnParent(wxVERTICAL);
   ...
   delete MyWin;
@@ -91,7 +91,7 @@ they are directly mapped to corresponding erlang terms:
   <dt><em>wxGridCellCoords</em> is represented by {Row,Column}</dt>
 </dl>
 
-In the places where the erlang api differs from the original one it should
+In the places where the erlang API differs from the original one it should
 be obvious from the erlang documentation which representation has
 been used. E.g. the C++ arrays and/or lists are sometimes represented
 as erlang lists and sometimes as tuples.
@@ -112,7 +112,7 @@ Additionally some global functions, i.e. non-class functions, exist in
 the <c>wx_misc</c> module.
 
 <em>wxErlang</em> is implemented as a (threaded) driver and a rather direct
-interface to the C++ api, with the drawback that if the erlang
+interface to the C++ API, with the drawback that if the erlang
 programmer does an error, it might crash the emulator.
 
 Since the driver is threaded it requires a <em>smp</em> enabled emulator,
@@ -121,7 +121,7 @@ that provides a thread safe interface to the driver.
 == Multiple processes and memory handling == 
 
 The intention is that each erlang application calls wx:new() once to
-setup it's gui which creates an environment and a memory mapping.  To
+setup it's GUI which creates an environment and a memory mapping.  To
 be able to use <em>wx</em> from several processes in your application,
 you must share the environment. You can get the active environment with
 <code>wx:get_env/0</code> and set it in the new processes
@@ -153,26 +153,26 @@ increasing memory usage. This is especially important when
 <em>wxWidgets</em> assumes or recommends that you (or rather the C++
 programmer) have allocated the object on the stack since that will
 never be done in the erlang binding. For example <code>wxDC</code> class
-or its sub-classes or <code> wxSizerFlags</code>. 
+or its sub-classes or <code>wxSizerFlags</code>. 
 
 Currently the dialogs show modal function freezes wxWidgets
 until the dialog is closed. That is intended but in erlang where you
-can have several gui applications running at the same time it causes
+can have several GUI applications running at the same time it causes
 trouble. This will hopefully be fixed in future <em>wxWidgets</em>
 releases.
 
 == Event Handling ==
 
-Event handling in <em>wx</em> differs most the from the original api.
+Event handling in <em>wx</em> differs most from the original API.
 You must specify every event you want to handle in <em>wxWidgets</em>,
-that is the same in the erlang binding but can you choose to receive
-the events as messages or handle them with callback funs.
+that is the same in the erlang binding but you can choose to receive
+the events as messages or handle them with callback  <em>funs</em>.
 
 Otherwise the event subscription is handled as <em>wxWidgets</em>
 dynamic event-handler connection. You subscribe to events of a certain
-type from objects with an <em>ID</em> or within a range of ID:s. The
-callback fun is optional, if not supplied the event will be sent to the
-process that called <em>connect/2</em>. Thus, a handler is a callback fun
+type from objects with an <em>ID</em> or within a range of <em>ID</em>s. The
+callback <em>fun</em> is optional, if not supplied the event will be sent to the
+process that called <em>connect/2</em>. Thus, a handler is a callback <em>fun</em>
 or a process which will receive an event message.
 
 Events are handled in order from bottom to top, in the widgets
@@ -195,7 +195,7 @@ subscribed to
 <em>wxKey</em> event record where <code>Event#wxKey.type =
 key_up</code>.
 
-In <em>wxWidgets</em> the developer have to call 
+In <em>wxWidgets</em> the developer has to call 
 <code>wxEvent:skip()</code> if he wants the event to be processed by
 other handlers. You can do the same in <em>wx</em> if you use
 callbacks. If you want the event as messages you just don't supply a
@@ -217,11 +217,11 @@ following handlers. The actual event objects are deleted after
 the <em>fun</em> returns.
 
 The callbacks are always invoked by another process and have
-exclusive usage of the gui when invoked. This means that a callback fun
+exclusive usage of the GUI when invoked. This means that a callback <em>fun</em>
 can not use the process dictionary and should not make calls to other
-processes.  Calls to another process inside a callback fun may cause a
+processes.  Calls to another process inside a callback <em>fun</em> may cause a
 deadlock if the other process is waiting on completion of his call to
-the gui.
+the GUI.
 
 == Acknowledgments ==