Windows Message Pump issue

2 posts / 0 new
Last post
Offline
Last seen: 10 years 3 months ago
Joined: 12/27/2013
Posts: 4
Windows Message Pump issue

Hi,

I downloaded the project code (CommandPattern.zip) associated with this article describing a "server/client" model using RTI --- The Command Pattern: Distributed RPC with QoS; since the project was somewhat "old", I needed to rerun "rtiddsgen" and feather in the changes appropriately. I rebuilt the Visual Studio "console" project (client & server sides) & was able to run the simple server/client test in the code - output provided in console windows.

I next ported the code to live in a "Windows" project - the initialization code is the same with the major difference of replacing an infinite loop with the Windows message pump loop ..

   ... "Server" code snippet was ---

    DDS_Duration_t span = {1,0};

   ...
    while(1)
    {
        NDDSUtility::sleep(span);
    }


    ---- is being replaced by this ...

    // Main message loop:
    while (GetMessage(&msg, NULL, 0, 0))
    {
        if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }

The server's incoming detection from the client request is not being "seen" -- I suspect the message pump is prohhibiting the listener "callback". When I remove the message pump code & put back in the infinite time delay, I then see incoming client requests as before.

Any ideas?


thx, Rich..

 

Keywords:
Offline
Last seen: 10 years 3 months ago
Joined: 12/27/2013
Posts: 4

I found the problem --- all the 'RTI' related threads were improperly exiting due to a software bug introduced when porting to (MFC) Windows. The "Command Server" class instance is a stack variable in a nested function - it was destroyed (by mistake) when returning from that function. A little code re-org solved it -- interesting experiment showed that two independant communication 'engines' (each defined in its own .IDL) could run together without collision. I'm wasn't sure about the best RTI strategy here; I initially thought a single "merged" ".IDL" file was required.