-
let's see....with my OnListBoxChanged() handling consisting of only constructing a lock (GetCurSel and SetWindowText and commented out), it deadlocks at:
1) CListBox::AddString from the read thread which is now created with AfxBeginThread
2) OnListBoxChanged with the final call at boost's win32::WaitForSingleObject
i'm thinking it's because i'm still calling AddString() in the read thread, which is a worker thread, not GUI thread. i was wondering why MFC doesn't throw exceptions all over the place like C# does if you don't use (Begin)Invoke(), but i think i know why now....it's got the same problems but doesn't let you know until later on when you've already written all the code!!
-
yep, the problem was AddString.
thanks for all the help guys. now i know a little more about the nuances of MFC :P
-
You probably would have the same issues if it were using just the Win32 API - due to the SendMessage() scenario I described earlier.
This is all CListBox::AddString() does:
Code:
_AFXWIN_INLINE int CListBox::AddString(LPCTSTR lpszItem)
{ ASSERT(::IsWindow(m_hWnd)); return (int)::SendMessage(m_hWnd, LB_ADDSTRING, 0, (LPARAM)lpszItem); }
The lesson to take away from this is: "keep UI in the main UI thread".
gg
