I am trying to integrate ZMQ into an existing windows application that relies heavily on MFC sockets (CASyncSocket).
I\'ve got a CWinThread derived UI thread (with
You could call zmq_recv() with the ZMQ_NOBLOCK flag inside your app's main message loop by overriding your CWinApp::OnIdle(). zmq_recv will return immediately if there is no data waiting on the socket. If there's data, handle it - but be aware that if you do something slow, you'll make the app unresponsive.
Edit: I didn't realize that OnIdle only gets called once when the message queue becomes empty. But according to MSDN's documentation, you can return a nonzero value to keep getting called forever:
OnIdle and supplies 0 as the lCount argument.OnIdle performs some processing and returns a nonzero value to indicate it should be called again to do further processing.OnIdle again, incrementing the lCount argument.OnIdle finishes processing all its idle tasks and returns 0. This tells the message loop to stop calling OnIdle until the next message is received from the message queue, at which point the idle cycle restarts with the argument set to 0.I also found this thread on GameDev.net where a user said:
All of the tools I have ever written in MFC that use D3D use the OnIdle() function:
BOOL CD3DEditorApp::OnIdle(LONG lCount)
{
// Call base class first
CWinApp:OnIdle( lCount );
// game stuff...
// Always return true - this asks the framework to constantly
// call the Idle function when it isn't busy doing something
// else.
return TRUE;
}
So, at least according to one person, it's a common technique.