Re: OnDocumentComplete
Joseph M. Newcomer wrote:
****
If you pass a CWnd* across a thread boundary, you must not allow the CWnd object to be
deleted until the thread is done using it. This is critical, because what will happen is
the thread could end up accessing free storage which might actually be reallocated for
some other object.
Isn't that general true as a rule of thumb of passing a pointer to a
thread that could be become invalid outside the thread?
What is CWnd* or HWND for the matter special in this regard?
Its a simple owner vs non-owner or z-order concept : if you didn't
create it, you shouldn't delete it unless it was specifically creates
for the thread to delete.
Its also relates to cross process or dll boundaries, it is not
recommended to create in one boundary and delete in another.
But if you pass the HWND, the common failure mode is
class CMyView : public CView {
protected:
static UINT handler(LPVOID p);
..
}
AfxBeginThread(handler, this);
/*static */ UINT CMyView::handler(LPVOID p)
{
CMyView * view = (CMyView *)p;
// this works correctly
}
But I've seen people who are told "You must pass the HWND because I once read a document
that said passing CWnd * is a Bad Idea" do the following
AfxBeginThread(handler, (LPVOID)m_hWnd);
/* static */ UINT CMyView::handler(LPVOID p)
{
CMyVIew * view = (CMyView*)CWnd::FromHandle((HWND)p);
}
OK, here's a Quickie Quiz: What's wrong with the above code? And why is it a Really
Really Bad Idea?
Thats easy, two things:
1) you are asking for something that is managed in some global table
(a map in this case)
2) if its not found, a new one is created, and the thread will not
know that fact in order to delete it.
This is old material, but MFC historically used TLS to maintain its
recording of Windows and handles per thread and across boundaries
(i.e. a MFC DLL) that was problematic, especially for use MFC based
objects, i.e, CString So in MFC 4.0, it uses a set of template
classes to wrap process level data. For example, this is a little
known trick and it works extremely work:
struct CMyProcessData : public CNoTrackObject;
{
CString s;
}
struct CMyThreadData : public CNoTrackObject;
{
CString s;
}
CProcessLocal<CMyProcessData> MyProcessData;
CThreadLocal<CMyThreadData> MyThreadData;
void SetProcessString(LPCTSTR lpsz) { MyProcssData->s = lpsz; }
void SetThreadString(LPCTSTR lpsz) { MyThreadData->s = lpsz; }
CString GetProcessString() { return MyProcssData->s; }
CString GetThreadString() { return MyThreadData->s; }
When you start a thread, it will automatically get its own instance of
CMyThreadData. I use this for a few dlls that creates threads and it
allows me to maintain MFC safe process and thread state information
when using MFC objects.
This is documented in a MSDN Tech Note:
TN058: MFC Module State Implementation.
http://msdn.microsoft.com/en-us/library/ft1t4bbc(VS.80).aspx
This is one of those subtleties of where MFC Meets System Programming that I talk about in
my course.
(RAISING HAND!)
Isn't it better to as a general practice of pointer usage to
understand how memory is used rather than making everything else fit
under MFC?
Understanding MFC is important, but following basic concepts of
z-order programming inherently solves 99.99% (if not 100%) of the
design questions to a point it doesn't become a question at all.
One of the problems (and goran we had this discussion before) with
using higher layer tools, is that it increases the understanding
requirements that can be become very subtle and quite often requires a
DEEP understanding of the higher layer wrappings itself missing
critical points of the basic underlining framework.
Example, this is something I'm currently working on with touches based
with this idea of z-order and pointer ownerships and usage;
Asynchronous RPC using a I/O completion port notification type. There
is no MSDN example only a Event based notification type. Googling
shows no results and the closest one is so complex with an extremely
rich library that is dependent on so many other things that not even
downloading the source and reviewing the code was difficult to see
what is the basic framework to get it done.
This required rolling up the sleeve and trying various ideas using the
"raw" IOCP and ASYNC RPC API functions, re-reading the MSDN docs as
you see results until you finally understand whats going on and get
the layout right. I just now at this moment reached that point and
took a timeout to read the MFC forum.
The irony is now I will be wrapping it with my own classes to make it
easy. I can only do that one you understand the basics.
--
HLS