我建了一个单文档工程SockData,主视图的基类为FormView,我在MainFrame里面创建了一个新线SocketThread,
CreateThread(NULL,0,SocketThread,this,0,NULL),CMainFrame::SocketThread(LPVOID lparam)
建立好Socket连接后,SocketThread接收数据,我想将接受到的数据在FormView里面显示出来,于是想这样获取指针进行通讯,不知道为什么不行:
     CMainFrame* pSocket = (CMainFrame*)lparam;
     CFormView* pFormView = (CFormView*)pSocket->GetFormView();
     //其中的GetFormView是我自己写的一个从MainFrame获取CFormView指的一个函数
     
     pFormView->OnShowData(&Data);
     //OnShowData(&Data)是在CFormView里面显示接收到的数据的函数为什么 CFormView* pFormView = (CFormView*)pSocket->GetFormView();这样获取指针有问题,程序跑到这里就崩掉了,该怎么样才对呀

解决方案 »

  1.   

    改用线程给CFormView窗口发送消息,创建线程的时候就将CFormView的窗口句柄HWND传递给线程函数,在线程中发送自定义的消息到CFormView窗口,在CFormView类的自定义的消息响应函数中去处理。另外创建线程使用AfxBeginThread()来创建,不要使用CreateThread
      

  2.   

    MFC对象不是线程安全的,有些成员函数是不能在创建这个对象以外的线程里调用的。安全的做法是:按照1楼的方法
      

  3.   

       按一楼说的话,那线程访问MainFrame时又有问题,而且用消息的话线程接收到的数据在结构体里,有点不好传递吧
      

  4.   

    还发现一个奇怪的问题,我把debug换成release就好了,可返回用debug还是不行,不知道什么回事
      

  5.   

    在MainFrame中获取CView指针的方法,MSDN中有函数说明
    获得CView: 
    -在CDocument中 POSITION pos = GetFirstViewPosition();GetNextView(pos) 
    -在CChildFrame中 GetActiveView() 
    -在CMainFrame中 
      -if SDI:GetActiveView() 
      -if MDI:MDIGetActive()->GetActiveView() 可见,在MainFrame中,只要使用GetActiveView()函数即可获取CView的指针。
      

  6.   

       楼上的可能没看明白我说的意思,GetFormView()这个函数就是从MainFrame获取CFormView的指针,而且我在别的地方调用过,这个函数没问题。可是我从线程里面先获取父窗口MainFrame的指针pSocket ,然后再调用GetFormView()这个函数获取FormView的指针就出问题了
      

  7.   

    debug下是有断言检测的
    release没有这个机制但并不代表这里永远不会出问题
    最合理的方法还是像一楼说的发消息
    你说的关于结构体数据的问题
    可以考虑用全局标量做公共缓冲来传递数据
      

  8.   

    3#:难道你线程里既要访问框架类,又要访问视图类?
    6#:这个问题很正常,看2L,详细点的请看下面
    SUMMARY
    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. 
    Back to the topMORE INFORMATION
    In a Win32 process, all the threads running in the process address space can view all global and static data. A thread can use thread-local-storage (TLS) to store any thread-specific data. In a multi-threaded environment because windows are owned by threads, MFC keeps the temporary and permanent window handle map in thread local storage. The same is true for other handle maps like those for GDI objects and device contexts. Keeping the window handle maps in thread local storage ensures protection against simultaneous access by several threads. The behavior of the functions CHandleMap::LookupPermanent() and CHandleMap::LookupTemporary() is a direct consequence of these facts. Given a window handle, these functions check the permanent and temporary window handle maps of the current thread for the existence of an associated CWnd derived MFC object. This means that if calls to these functions are made from a thread to search for MFC objects that represent windows created in other threads, these calls will fail. There are several functions that call CHandleMap::LookupPermanent() and CHandleMap::LookupTemporary(). CWnd::AssertValid() (and hence the macro ASSERT_VALID for a CWnd object) is one such function. This function is called to make validity checks on an object. If AssertValid() fails to find an entry for the MFC object's m_hWnd member in any of the handle maps or finds an incorrect entry, it fires an assertion. In Visual C++ 2.1, these assertions are in file Wincore.cpp, lines 797 and 798. In Visual C++ 2.2, they are in Wincore.cpp, lines 804 and 805. In Visual C++ 4.0, they are in Wincore.cpp, lines 871 and 872. Calls to the ASSERT_VALID macro are sprinkled all over the MFC source code. Hence, from a particular thread, if you end up calling a function that calls ASSERT_VALID on MFC window objects that belong to some other thread, you get an assertion. If you do not get an assertion, you may still get abnormal behavior because you are not allowed to directly manipulate windows created by other threads. The correct approach in such situations is to work with window handles, not MFC objects. It is safe to pass window handles across thread boundaries. If thread A passes a window handle to thread B, then thread B can use this window handle to send or post messages to the window. When these messages are processed, you are back in the context of thread A and calls to CWnd::AssertValid() to check thread A's window handle maps will succeed. In this scenario, thread B can also use the CWnd::FromHandle() function to get a temporary CWnd object which is placed in thread B's temporary handle map. However this object may be of only limited use, because in no way is it in synchronization with the MFC object existing in thread A's handle maps. 
      

  9.   

    还是不行呀 下面是我的部分代码 大家看看有什么问题没
    先是在CMainFrame里面建立Socket连接
      

  10.   

    mfc界面跨线程访问,是不允许的。
      

  11.   

    在CMainFrame里面
    CFormView* pFormView = (CFormView*)GetFormView();//获取CFormView的指针
    if(m_Socket.Open(pFormView ))   //Socket是CMySocket的一个对象
       ......
    else
       ......
    然后我在CMySocket里面实现Open(Cwnd* pWnd)
    BOOL CMySocket::Open(Cwnd* pWnd)
    {
       ......
       m_pParentWnd = pWnd   //头文件定义 CWnd* pParentWnd ;
       ......
       CreateThread(NULL,0,SocketThread,this,0,NULL);
       ......
    }
    //然后实现SocketThread接收数据,并发送到CFormView
    DWORD CMySocket::SocketThread(LPVOID lparam)
    {
       CMySocket* pSocket;
       pSocket = (CMySocket*)lparam;
       ......
        ......
    //接收到数据后用SendMessage发送到CFormView显示
       ........
       SendMessage(pSocket->pParentWnd->m_hWnd,UM_SHOW_DATA,0,(LPARAM)&m_Struct_Data );
       //pSocket->pParentWnd->m_hWnd 这个指向CFormView有没有问题?????????????
       //UM_SHOW_DATA这是我的自定义消息
       //m_Struct_Data是我接收到的数据
    }
    可是不知道怎么回事程序跑起来十多分钟后会出现提示什么  必需的资源无法得到  的错误提示
      

  12.   


    可我用SendMessage还是有问题呀 我上面的代码问题出在哪里呀
      

  13.   

    TLS引起的问题,网上都说用发消息的方式,我也在纠结这个问题