Blind fix for bug #1209944, wxFileConfig constructor corrupts the stack

[wxWidgets.git] / src / os2 / listctrl.cpp

diff --git a/src/os2/listctrl.cpp b/src/os2/listctrl.cpp
index 1cf40a8c99f60fb0e6f607d027d42bac8eff0adb..366f156d7318289367ca141fe29dcee36cdba080 100644 (file)
--- a/src/os2/listctrl.cpp
+++ b/src/os2/listctrl.cpp
@@ -69,11 +69,11 @@
 //   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.
@@ -116,7 +116,7 @@ typedef struct _MYRECORD
 //
 // 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).
 //