Got generic wxListCtrl, wxTreeCtrl working under Windows, wxNotebook almost;

some doc corrections; Win16 dialog crash cured


git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@1255 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

docs/latex/wx/evthand.tex

@@ -28,6 +28,39 @@ Destructor. If the handler is part of a chain, the destructor will
 unlink itself and restore the previous and next handlers so that they point to
 each other.
 
+\membersection{wxEvtHandler::Connect}\label{wxevthandlerconnect}
+
+\func{void}{Connect}{\param{int}{ id},
+ \param{wxEventType }{eventType}, \param{wxObjectEventFunction}{ function},
+ \param{wxObject*}{ userData = NULL}}
+
+\func{void}{Connect}{\param{int}{ id}, \param{int}{ lastId},
+ \param{wxEventType }{eventType}, \param{wxObjectEventFunction}{ function},
+ \param{wxObject*}{ userData = NULL}}
+
+Connects the given function dynamically with the event handler, id and event type. This
+is an alternative to the use of static event tables. See the 'dynamic' sample for usage.
+
+\wxheading{Parameters}
+
+\docparam{id}{The identifier (or first of the identifier range) to be associated with the event handler function.}
+
+\docparam{lastId}{The second part of the identifier range to be associated with the event handler function.}
+
+\docparam{eventType}{The event type to be associated with this event handler.}
+
+\docparam{function}{The event handler function.}
+
+\docparam{userData}{Data to be associated with the event table entry.}
+
+\wxheading{Example}
+
+\begin{verbatim}
+  frame->Connect( wxID_EXIT,
+    wxEVT_COMMAND_MENU_SELECTED,
+    (wxObjectEventFunction) (wxEventFunction) (wxCommandEventFunction) MyFrame::OnQuit );
+\end{verbatim}
+
 \membersection{wxEvtHandler::Default}\label{wxevthandlerdefault}
 
 \func{virtual long}{Default}{\void}

docs/latex/wx/icon.tex

@@ -76,7 +76,8 @@ Creates a new icon.
 
 Creates an icon from XPM data.
 
-\func{}{wxIcon}{\param{const wxString\& }{name}, \param{long}{ type}}
+\func{}{wxIcon}{\param{const wxString\& }{name}, \param{long}{ type},
+  \param{int}{ desiredWidth = -1}, \param{int}{ desiredHeight = -1}}
 
 Loads an icon from a file or resource.
 
@@ -88,6 +89,14 @@ Loads an icon from a file or resource.
 
 \docparam{height}{Specifies the height of the icon.}
 
+\docparam{desiredWidth}{Specifies the desired width of the icon. This
+parameter only has an effect in Windows (32-bit) where icon resources can contain
+several icons of different sizes.}
+
+\docparam{desiredWidth}{Specifies the desired height of the icon. This
+parameter only has an effect in Windows (32-bit) where icon resources can contain
+several icons of different sizes.}
+
 \docparam{depth}{Specifies the depth of the icon. If this is omitted, the display depth of the
 screen is used.}
 

docs/latex/wx/paintdc.tex

@@ -3,7 +3,8 @@
 A wxPaintDC must be constructed if an application wishes to paint on the
 client area of a window from within an {\bf OnPaint} event.
 This should normally be constructed as a temporary stack object; don't store
-a wxPaintDC object.
+a wxPaintDC object. If you have an OnPaint handler, you {\it must} create a wxPaintDC
+object within it even if you don't actually use it.
 
 Using wxPaintDC within OnPaint is important because it automatically
 sets the clipping area to the damaged area of the window. Attempts to draw

docs/latex/wx/tdnd.tex

@@ -15,37 +15,36 @@ Headers: <wx/dataobj.h>, <wx/dropsrc.h and <wx/droptgt.h>>
 
 This overview describes wxWindows support for drag and drop and clipboard
 operations. Both of these topics are discussed here because, in fact, they're
-quite related. Drag and drop and clipboard are just too ways of passing the
+quite related. Drag and drop and clipboard are just two ways of passing the
 data around and so the code required to implement both types of the operations
 is almost the same.
 
-Both operations involve passing some data from one program to another
-(although the data may be received in the same program as well). In the case
-of clipboard transfer, the data is first places on the clipboard and then
-pasted into the destination program while for a drag-and-drop operation the
+Both operations involve passing some data from one program to another,
+although the data can be received in the same program as the source. In the case
+of clipboard transfer, the data is first placed on the clipboard and then
+pasted into the destination program, while for a drag-and-drop operation the
 data object is not stored anywhere but is created when the user starts
-dragging and is destroyed as soon as he ends it (whether the operation was
-ended successfully or cancelled).
+dragging and is destroyed as soon as he ends it, whether the operation was
+ended successfully or cancelled.
 
 To be a {\it drag source}, i.e. to provide the data which may be dragged by
-user elsewhere you should implement the following steps:
+user elsewhere, you should implement the following steps:
 
 \begin{itemize}\itemsep=0pt
 \item {\bf Preparation:} First of all, the data object must be created and
-initilized with the data you wish to drag. For example:
+initialized with the data you wish to drag. For example:
 
 \begin{verbatim}
 	wxTextDataObject data("This string will be dragged.");
 \end{verbatim}
 
 Of course, the data object may contain arbitrary data of any type, but for
-this you should derive your own class from 
-\helpref{wxDataObject}{wxdataobject} overriding all of its pure virtual
+this you should derive your own class from \helpref{wxDataObject}{wxdataobject} overriding all of its pure virtual
 functions.
 
 \item{\bf Drag start:} To start dragging process (typically in response to a
-mouse click) you must call \helpref{DoDragDrop}{wxdropsourcedodragdrop}
-function of wxDropSource object which should be constructed like this:
+mouse click) you must call \helpref{DoDragDrop}{wxdropsourcedodragdrop} function
+of wxDropSource object which should be constructed like this:
 
 \begin{verbatim}
 	wxDropSource dragSource(data, this);
@@ -63,8 +62,8 @@ same drag-and-drop protocol (any program under Windows or any program supporting
 under X Windows), the corresponding \helpref{wxDropTarget}{wxdroptarget} methods
 are called - see below.
 
-\item {\bf Processing the result:} DoDragDrop() returns an {\it effect code}
-which is one of the values of \helpref{wxDragResult}{wxdragresult} enum. Codes
+\item {\bf Processing the result:} DoDragDrop() returns an {\it effect code} which
+is one of the values of \helpref{wxDragResult}{wxdragresult} enum. Codes
 of wxDragError, wxDragNone and wxDragCancel have the obvious meaning and mean
 that there is nothing to do on the sending end (except of possibly logging the
 error in the first case). wxDragCopy means that the data has been successfully
@@ -72,10 +71,8 @@ copied and doesn't require any specific actions neither. But wxDragMove is
 special because it means that the data must be deleted from where it was
 copied. If it doesn't make sense (dragging selected text from a read-only
 file) you should pass FALSE as parameter to DoDragDrop() in the previous step.
-
 \end{itemize}
 
-
 To be a {\it drop target}, i.e. to receive the data dropped by user you should
 follow the instructions below:
 
@@ -91,8 +88,8 @@ or OnDropFiles() method.
 
 \item {\bf Drop:} When the user releases the mouse over a window, wxWindows
 queries the associated wxDropTarget object if it accepts the data. For
-this, \helpref{GetFormatCount}{wxdroptargetgetformatcount} and
-\helpref{GetFormat}{wxdroptargetgetformat} are used and if the format is
+this, \helpref{GetFormatCount}{wxdroptargetgetformatcount} and \helpref{GetFormat}{wxdroptargetgetformat} are
+used and if the format is
 supported (i.e. is one of returned by GetFormat()), 
 then \helpref{OnDrop}{wxdroptargetondrop} is called. 
 Otherwise, \helpref{wxDragNone}{stdformat} is returned by DoDragDrop() and
@@ -102,6 +99,5 @@ nothing happens.
 wxDragCopy or wxDragMove depending on the state of the keys (<Ctrl>, <Shift>
 and <Alt>) at the moment of drop. There is currently no way for the drop
 target to change this return code.
-
 \end{itemize}
 

docs/msw/changes.txt

@@ -2,6 +2,16 @@
 wxWindows 2.0 for Windows Change Log
 ------------------------------------
 
+Alpha 18, December 23nd 1998
+----------------------------
+
+- Win16 support working again (VC++ 1.5)
+- Win16 now uses generic wxNotebook, wxListCtrl,
+  wxTreeCtrl -- more or less working now, although
+  a little work on wxNotebook is still needed.
+  Under 16-bit Windows, get assertion when you click
+  on a tab.
+
 Alpha 17, November 22nd 1998
 ----------------------------
 

docs/msw/install.txt

@@ -56,11 +56,8 @@ Visual C++ 1.5 compilation
 
 1. Change directory to wx\src\msw. Type 'nmake -f makefile.dos' to
    make the wxWindows core library.
-2. Change directory to wx\samples and type 'nmake -f makefile.dos'
-   to make all the samples. You can also make them individually.
-
-NOTE: 16-bit compilation is not recommended (see issues.txt):
-many things are broken, including dialog boxes.
+2. Change directory to a sample, such as wx\samples\minimal, and
+   type 'nmake -f makefile.dos'.
 
 Borland C++ 4.5/5.0 compilation
 -------------------------------

docs/msw/issues.txt

@@ -8,7 +8,3 @@ This conflicts with wxUSE_IOSTREAMSH = 0 using MS VC++ 5.0
 (crashes the template code). It should be switched off if you
 wish to use wxUSE_IOSTREAMSH = 0.
 
-Many things seem to be broken for 16-bit Windows, including
-dialogs (crash in wxFindWinFromHandle). The generic tree, list
-and notebook controls don't work. The generic wxImageList drawing
-function doesn't work (wxDC::SelectObject problem).