MFC中跨线程UpdateData(FALSE)报错 ASSERT FAILD问题
文章来自:http://hi.baidu.com/yu_xiyan/item/27f82bf1a1cc0813d7ff8c8c
MFC程序,在给控件关联的变量赋值后,需要调用UpdateData(FALSE)后才能更新到界面,但是有时候却报错:
断言宏失败,在wincore.cpp的如下位置:
CObject* p=NULL;
if(pMap)
{
ASSERT( (p = pMap->LookupPermanent(m_hWnd)) != NULL ||
(p = pMap->LookupTemporary(m_hWnd)) != NULL);
}
ASSERT((CWnd*)p == this); // must be us
这个问题其实是由于跨线程访问UI元素导致的,微软在MSDN中做了如下描述:
In a multi-threaded application written using MFC, you should not pass MFC objects across thread boundaries. As a general rule, a thread should access only those MFC objects that it creates. Failure to do so may cause run-time problems including assertions or unexpected program behavior.
也就是说,MFC的UI线程是线程相关的,每个窗口的HandleMap是储存在创建UI那个线程的堆栈里面的(thread-local-storage (TLS) ),所以,你要是在另一个线程里面通过某种方式调用UI的UpdateData(FALSE)函数,他将无法正确执行。
知道了原因就好办事了,下面提供两种解决方法:
1、通过GetDlgItem(IDC_XXX)取得控件后SetWindowText()
这种方式之所以能得逞,是因为调用SetWindowText 会导致 WM_SETTEXT被发送给目标窗体,由消息机制负责处理:
ctrlDlg->GetDlgItem(IDC_EDIT19)->SetWindowText(A2W(pData));
2、自定义一个消息,将Update消息发送到UI线程,在UI线程的对话框中处理消息,自己执行UpdateData(FALSE)函数的调用。
申明:如果未加转载说明,本文即为原创文章
转载请注明:转自Roboby's Home
本文链接:MFC中跨线程UpdateData(FALSE)报错 ASSERT FAILD问题
————————————————————-
以下来自csdn
===================arthur======
在MFC中,user句柄和gdi句柄等是对应着一组对象(并不是所有句柄),它们是通过映射关系保存在一个叫做“模块线程状态”里面的,这个“模块线程状态”是属本地线程所拥有的,所以如果在其它的线程中查找句柄对应的对象指针是找不到指定的永久对象指针的,而维护这些句柄与对象指针的映射关系的,就是靠CHandleMap类型,其中楼主所说的
afxMapHWND()
是去取当前线程状态中的当前模块状态里面的当前模块线程状态中所保存的窗口句柄与其对象映射的
CHandleMap类型的指针,在这个线程中没有一次去创建这个映射的指针时,用户如果调用了afxMapHWND()那么它就返回NULL,这时ASSERT(pMap!=NULL)就会现现断言失败,在DEBUG下面当然会跳出错误了。
MFC关于多线程中传递窗口类指针时ASSERT_VALID出错的另类解决 转
在多线程设计中,许多人为了省事,会将对话框类或其它类的指针传给工作线程,而在工作线程中调用该类的成员函数或成员变量等等。
但是在Debug版本时,在某些情况下,特别是在工作线程中调用pWnd->UpdateData(FALSE)时,会出现错误。
这个错误的原因网上有许多地方讲到了,但是,令人失望的是,讲得好的没几篇,都是非要讲什么线程模块状态什么的,让人看得云里雾里(不过,说实话,也就是从这些文章中才知道是怎么回事的)。
其实本人以为,说穿了,很简单,避免多线程冲突,下面举例说明:
在你的对话框类中有一编辑框和一按钮,编辑框关联了变量为m_strText
现在在你按下按钮时,你有代码如下:
m_strText = "Hello";
UpdateData(FALSE);
在正常情况下你的编辑框中很显然会显示出"Hello"来。
但是,不怕一万,就怕万一,偏偏在你m_strText="Hello"这个代码执行之后,你的线程切换了,可是在你的工作线程里,你却将m_strText设置成了"Sorry",结果当线程切换回来后,UpdateData(FALSE)后,编辑框上就变成"Sorry"而不是"Hello"了。
所以,MFC并不建议这种多线程中传递MFC对象的指针,而且MFC人为的加了一个ASSERT_VALID来表示它们的不建议。
但是,不建议并不表示不能用,如果你能够确认你的线程不会互相冲突,你就大胆的用吧。
正因为如此,MFC只是在Debug版本中才有这个ASSERT_VALID的问题存在,在Release版本中却没有,因为它没有理由来阻止我们用。
虽然如此,但是毕竟我们的调试许多时候是要用到Debug版本的,MFC的如此做法还是给我们带来了诸多不变,幸运的是,MFC将它的真正检测线程相关MFC对象的代码做成了虚拟函数,也就是说,我们可以重载它,这样在Debug时,也不会出这问题了。
下面,让我们热烈欢迎我们今天的主角出场--virtual void CObject::AssertValid( ) const;
ASSERT_VALID最后会调用MFC类对象的AssertValid函数,因此只要重载AssertValid,令其不检测与线程相关的这些东东,就不会弹出出错框了(其实这些出错框,本来就是人为的弹出来的)。
费话就不说了,假设我们的对话框是CTmthDlg,下面是重载后的代码
void CTmthDlg::AssertValid() const
{
if (m_hWnd == NULL)
return; // null (unattached) windows are valid
// check for special wnd??? values
ASSERT(HWND_TOP == NULL); // same as desktop
if (m_hWnd == HWND_BOTTOM)
ASSERT(this == &CWnd::wndBottom);
else if (m_hWnd == HWND_TOPMOST)
ASSERT(this == &CWnd::wndTopMost);
else if (m_hWnd == HWND_NOTOPMOST)
ASSERT(this == &CWnd::wndNoTopMost);
else
{
// should be a normal window
ASSERT(::IsWindow(m_hWnd));
// should also be in the permanent or temporary handle map
// Note: if either of the above asserts fire and you are
// writing a multithreaded application, it is likely that
// you have passed a C++ object from one thread to another
// and have used that object in a way that was not intended.
// (only simple inline wrapper functions should be used)
//
// In general, CWnd objects should be passed by HWND from
// one thread to another. The receiving thread can wrap
// the HWND with a CWnd object by using CWnd::FromHandle.
//
// It is dangerous to pass C++ objects from one thread to
// another, unless the objects are designed to be used in
// such a manner.
}
}
这里我只是简单的从CWnd::AssertValid中拷贝来,然后注释掉检测线程中MFC对象和Windows对象映射的代码。
另外,请注意一下MFC自己的一些注释。
// It is dangerous to pass C++ objects from one thread to
// another, unless the objects are designed to be used in
// such a manner.
现在,请在你的工作线程中调用
((CTmthDlg*)pParam)->UpdateData(FALSE);
然后调试运行,一切工作正常。
南来地,北往的,上班的,下岗的,走过路过不要错过!
======================个性签名=====================
之前认为Apple 的iOS 设计的要比 Android 稳定,我错了吗?
下载的许多客户端程序/游戏程序,经常会Crash,是程序写的不好(内存泄漏?刚启动也会吗?)还是iOS本身的不稳定!!!
如果在Android手机中可以简单联接到ddms,就可以查看系统log,很容易看到程序为什么出错,在iPhone中如何得知呢?试试Organizer吧,分析一下Device logs,也许有用.