// headers
// ----------------------------------------------------------------------------
-#ifdef __GNUG__
- #pragma implementation "listctrl.h"
- #pragma implementation "listctrlbase.h"
-#endif
-
// For compilers that support precompilation, includes "wx.h".
#include "wx/wxprec.h"
// how many records the view will have, initially, and how many columns
// the detail view of the container will have, as the container represents
// a known data block. Thus the OS/2 PM CV_DETAIL view, i.e.
-// the wxWindows wxLC_REPORT view, relies on STATIC structure for its
+// the wxWidgets wxLC_REPORT view, relies on STATIC structure for its
// columnar data. It gets the data to display by telling it the specific
// offset of the field in the struct containing the displayable data. That
// data has be of OS/2 Types, PSZ (char string), CDATE or CTIME format.
-// wxWindows is dynamic in nature, however. We insert columns, one at a
+// wxWidgets is dynamic in nature, however. We insert columns, one at a
// time and do not know how many until the app is done inserting them. So
// for OS/2 I have to set a max allowable since they are fixed. We return
// an error to the app if they include more than we can handle.
//
// Solution:
// Under MSW the only way to associate data with a
-// List item independant of its position in the list is to store a pointer
+// List item independent of its position in the list is to store a pointer
// to it in its lParam attribute. However user programs are already using
// this (via the SetItemData() GetItemData() calls).
//
return lRc;
} // end of wxListCtrl::WindowProc
-wxListView::wxListView()
-{
-}
-
-wxListView::wxListView(wxWindow *parent,
- wxWindowID winid,
- const wxPoint& pos,
- const wxSize& size,
- long style,
- const wxValidator& validator,
- const wxString &name)
-{
- Create(parent, winid, pos, size, style, validator, name);
-}
-
#endif // wxUSE_LISTCTRL