描述:
Lop5217辛苦了，希望今后能向你请教
To csdn众捕头及斑竹,详见帖子
http://expert.csdn.net/Expert/topic/2996/2996499.xml?temp=.8085749
解决方案1:
对于楼主原帖中的第一个问题，正如楼主所说，“因为pInst接口所属控件处在主线程套间”。因为pInst实际是指向代理对象的指针，而当pInst->StartWorkThread();时，实际调用代理对象实现的IDEventTest。
如果是在STA套间中发起上面的调用，为了保障STA的线程规则，其向主线程中的隐藏窗口发送一个消息，但是是Post而并非Send，然后其进入一个COM模式循环。而所谓的COM模式循环，实际就是一个消息循环，不同的是此循环在检测到消息后，根据消息的种类（是发给隐藏窗口的消息还是一般普通消息）调用和此线程绑定的一个COM对象，此对象实现IMessageFilter以保证此线程（即工作者线程）中的STA组件对象不会因为等待另一个同步调用的返回而不能做出反应。
如果是在MTA套间中发起，则只是简单的MsgWaitForMultiObjects以表现出是同步调用（因为逻辑上规定STA中的对象的代码只能由此STA相关的线程执行）。
对于第二个问题，抱歉那个代码已经没有了，我记不到ThreadFunction里是什么代码了，不过不管是什么。因为是直接通过类的成员函数调用这种访问方式，即ThreadFunction不是一个虚函数进而函数地址是编译时期就定好了，且pInstance是一个类对象的指针，没有通过汇集操作，编译时就被编译成直接调用那个成员函数。也就是说前面的什么发送消息、进入模式循环等都是代理对象的代码导致的，而此处没有代理对象，故执行循环的是工作者线程而并非原来的主界面线程。
而pInstance是一个CEventTestCtrl*，重点就是它是从CWnd派生来的，语义上是界面包装类。对于MFC提供的界面包装类，由于特殊的原因，其是线程相关的，不能像楼主原来那样线程间直接传递类对象的指针，故而导致“FireEvent及一些界面更新类的函数如UpdateWindow”的调用出错，实际出错的并不是这些函数，而是其内部的ASSERT_VALID( this );断言宏。对于此，我专门写了一篇文章说明原因，楼主有兴趣可以参考：
http://www.csdn.net/Develop/read_article.asp?id=26152