MessageBox会导致异步网络接收函数不被触发吗？

[parterner]

近期在用MFC做一个软件，软件与服务器通讯，服务器与客户端均在本机，客户端下发指令给服务器，服务器上发相应内容给客户端。发送由用户点击按钮，调用send函数发送；接收则采用异步接收，重写了CAsyncSocket类的Onreceive函数。希望的效果是下发之后500ms内收到相应回复数据。
目前遇到一个问题，想做一个用户确认的功能，目前做法是用MessageBox弹框，确认之后再进行下发，下发在另外开启的线程中进行。
但是发现加入了这个MessageBox之后，经常会出现点击确认之后Onreceive函数不被调用，但是在下发超时之后（也就是发送失败之后）才会收到数据。从服务器端日志来看，服务器端确实在合适的时间将数据上发了，但是就是无法触发，最后一次发送失败之后收到正确数据。因为是本机网络，不考虑网络延时。
刚开始以为网络有问题，一直找不到原因。直到偶然把提示的确认框相关代码注释掉之后发现这个Onreceive函数可以被正常触发。所以感觉是MessageBox这边出了问题。

t = MessageBox(this->GetSafeHwnd(),"确认下发参数？","下发参数",MB_YESNO | MB_ICONWARNING);
if(t == IDNO) return;

所以不知道这种情况由何引起，又该如何解决？请大家帮忙看看

[三岁、就很帅]

你试下用afxmessagebox看看

[oyljerry]

messafebox会可能影响消息循环。导致aocket色消息也被影响

[parterner]

我又确实需要根据用户的选择来决定是否下发，所以此处必须得有阻塞。请问大家有没有其他的控件可以解决这个问题呢？

[encoderlee]

下发在另外开启的线程中进行 是什么意思？ 要注意在默认情况下，CAsyncSocket和CSocket对象不能跨线程使用。

[oyljerry]

把messageBox提前放到其他地方，或者在界面UI线程中处理

[schlafenhamster]

自己做个 Modeless 对话框 （create）， 不行吗 ？

[parterner]

就是在用户确认过messageBox之后，调用发送函数，函数中启动线程下发参数，用send。 线程会等待一段时间（这里设计的是500ms），这段时间内如果收到数据，标志位置位，退出线程。 在发送函数中等待线程结束，使用的是waitforMultipleobjects，同时也建立有消息循环保证消息不被阻塞。 等待线程结束部分是这么写的：

        RefreshResult=AfxBeginThread(DownloadParaThread,(LPVOID)&index); 
	if (RefreshResult != NULL) 
	{ 
		DWORD dwRet=0;
		MSG msg;  
		while (TRUE)  
		{  
			dwRet = MsgWaitForMultipleObjects (1, &RefreshResult->m_hThread,   FALSE, INFINITE, QS_ALLINPUT);  
			if(dwRet==WAIT_OBJECT_0)
				break;
			else if(dwRet==WAIT_OBJECT_0 + 1)
			{
				PeekMessage(&msg, NULL, 0, 0, PM_REMOVE);  
				DispatchMessage(&msg); 
			}
			else
				break;
		}
		RefreshResult = NULL;
	} 

直观上感觉是在下发send函数调用之后，Onreceive函数就无法被触发，但是偶尔又会有被触发的情况，也不是每次都失败，只是失败的概率比较大。但是如果将前面MessageBox代码段删掉之后，OnReceive函数就可以正常触发。所以才定位到MessageBox的影响。你们感觉如何呢？

[parterner]

而且我不仅仅是在MessageBox存在的时候不能触发，关掉MessageBox之后也不能触发。

[parterner]

MessageBox处理结束之后才会调用函数启动线程，就是感觉是不是MessageBox虽然通过点击OK或者cancek结束了但是它还是会影响到后面线程的启动。

[parterner]

我正准备自己画一个对话框，然后DoModal调用，看看是否存在问题。

[schlafenhamster]

是不是要 调用 WM_CANCELMODE ？？ void CCancelModeDlg::OnSetfocusEdit2() { if(!FindWindow(0,"yyy"))// change : AFX_IDS_APP_TITLE="yyy" { AfxMessageBox("SetfocusEdit2"); // w.o this， the cursor is 'I' anywhere ,means focus in edit2 !!! // mouse has captured by edit2 m_Edit2.PostMessage(WM_CANCELMODE,0,0); } }

[parterner]

自己做了一个对话框，用DoModal()启动，发现Onreceive函数还是会被推迟触发的情况。不知道WM_CANCELMODE 是什么意思呢？？

[schlafenhamster]

SUMMARY In the Microsoft Windows graphical environment, the WM_CANCELMODE message informs a window that it should cancel any internal state. This message is sent to the window with the focus when a dialog box or a message box is displayed, giving the window the opportunity to cancel states such as mouse capture. When a control has the focus, it receives a WM_CANCELMODE message when the EnableWindow function disables the control or when a dialog box or a message box is displayed. When a control receives this message, it should cancel modes, such as mouse capture, and delete any timers it has created. A control must cancel these modes because an application may use a notification from the control to display a dialog box or a message box. The DefWindowProc function processes WM_CANCELMODE by calling the ReleaseCapture function, which cancels the mouse capture for whatever window has the capture. The DefWindowProc function does not cancel any other modes.

[蒋晟]

CAsyncSocket有做防无限重入，避免你这样MessageBox阻塞之后又接受到新消息导致无数个MessageBox被弹出来。 你应该重新考虑下界面设计，比如用状态栏或者列表视图来显示信息。

[schlafenhamster]

“将前面MessageBox代码段” 改为 afxDump （不柱塞）看看

[赵4老师]

换TRACE

[parterner]

总结一下，是因为没有做好消息泵，没有把所有的信息都传入到消息循环，有一段代码如下： while (TRUE) { //wait for m_hThread to be over，and wait for //QS_ALLINPUT（Any message is in the queue） dwRet = MsgWaitForMultipleObjects (1, &cThread->m_hThread, FALSE, INFINITE, QS_ALLINPUT); switch(dwRet) { case WAIT_OBJECT_0: break; //break the loop case WAIT_OBJECT_0 + 1: //get the message from Queue //and dispatch it to specific window while(PeekMessage(&msg,NULL,0,0,PM_REMOVE)) { TranslateMessage(&msg); DispatchMessage(&msg); } continue; default: break; // unexpected failure } break; } cThread = NULL; } 红色部分就是问题的关键，因为之前没有加那个循环，导致的后果就是一旦出现对话框，将msg循环占用，就会导致异步网络接收函数的阻塞，最终导致问题的产生，加入循环之后问题解决，对话框的弹出与否不再影响网络的异步接收。 到这里看起来似乎问题已经结束，但是经过这个问题，我发现自己对于一些技术的理解还是太肤浅了，找到解决方案之后没办法去弄明白其中的具体道理，比如为什么加入了while循环之后消息循环就可以正常运行了，之前对话框的出现是为什么会导致这些问题的产生也都只是个人感觉问题所在，并没有参考书籍文献材料，以前看侯俊杰前辈的《深入浅出MFC》也只是略过一眼，没有去仔细专研其中细节深奥的部分。。 这里希望有相关经验或者对这个问题感兴趣的朋友们能够不吝赐教，讲解一下关于MFC消息循环的原理以及什么可能会影响消息循环。

[horris]

我认为你的异步设计有问题，导致了复杂的解决方案。 CAsycSocket实际上不是在工作者线程中等待接收数据的，它是运行在主线程环境中的，也就是和你的MessageBox所在的线程在一起的。之所以接收是异步的，应该是底层用了Overlapped IO之类的技术，而Overlapped IO的读写完成的通知是基于消息的，MessageBox阻塞了消息循环，使得CAsyncSocket不能及时触发OnReceived。你的解决方案是修改消息循环。 我个人不喜欢自定义消息循环这种高度依赖OS平台、造成程序不易读的技术。我倒以为，你应该将接收过程和发送过程一样，彻底放到另一个工作者线程中。这样一，不用自定义消息循环，有利于以后程序维护，也有利于程序移值到其它平台；不用CAsyncSocket，代码逻辑清晰。

[horris]

另外，觉得楼主异步发送后，等待发送线程结束那段代码太复杂，还用消息泵（我楼上称为消息循环，不严谨）。不如修改下，异步发送线程在结束前，清除另一个标志位，这个标志位表明是否在发送等待500ms中。这样，主线程就可以在用户重复发送前，判断此标志，如果标志置位，则提示用户“上一次发送正等回复中”之类的。主线程完全不必使用消息泵。 个人认为，越复杂就越容易出错，也不易后续维护和扩展，象MsgWaitForMultipleObjects 这种API坑很多的。

[kakabulusi]

MessageBox函数可以阻塞程序的正常执行的，