none
Replacement of WinCE message queue in win 10 RRS feed

  • Question

  • Hi All,

    I'm migrating my project from WinCE 6.0 to Win 10. I'm looking for the replacement of message queue in Win 10 but not much information I can get.

    The messageQueue is used to communication between a C# application and a C++ application.

    Is there any recommendation from Microsoft?

    Thank You.

    Regards,

    Geng88


    • Edited by Geng88 Thursday, September 12, 2019 9:10 AM Update requirement
    Thursday, September 12, 2019 9:04 AM

Answers

  • As I said, Windows has the desktop message queue. See Messages and Message Queues.

    Because desktop Windows isn't such a resource starved environment, you don't need to explicitly create a message queue using this type of function. A message queue will be created automatically for the thread whenever you use the message queue functions, like GetMessage or PeekMessage.

    While you can use a message only window if you don't have a window in your application, you can also use PostThreadMessage to post messages to a different thread, even if that thread is in a completely different process.

    So you have a message queue available to you.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Edited by Darran Rowe Friday, September 13, 2019 4:38 AM
    • Marked as answer by Geng88 Monday, September 16, 2019 3:33 AM
    Friday, September 13, 2019 4:37 AM

All replies

  • Hello,

    please provide more information. Describe your message queue and how you communicate between the applications. What do you want to replace?

    Regards, Guido

    Thursday, September 12, 2019 10:12 AM
  • Well, Windows 10 has the desktop's message queue. C# can use platform invoke. So is there really a need to find a replacement?


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Thursday, September 12, 2019 5:39 PM
  • Hello Guido,

    My previous c++ and c# applications were executed in an ARM processor platform. These two applications had to talk to each other. Hence, both of the c++/c# applications utilized the functions provided in WinCE 6.0 msgqueue.h and winbase.h to form the communication.

    winbase.h
    - MSGQUEUEOPTIONS

    msgqueue.h
    1) CreateMsgQueue
    2) ReadMsgQueue
    3) WriteMsgQueue
    4) CloseMsgQueue

    Since I'm moving my application to a new platform (Intel processor), the MsgQ feature provided above are not available in Win10, I wonder is there any recommendation from Microsoft for the replacement of WinCE 6.0 MsgQ feature in Win 10?

    Thank You.

    Regards,
    Geng88

    Friday, September 13, 2019 3:28 AM
  • As I said, Windows has the desktop message queue. See Messages and Message Queues.

    Because desktop Windows isn't such a resource starved environment, you don't need to explicitly create a message queue using this type of function. A message queue will be created automatically for the thread whenever you use the message queue functions, like GetMessage or PeekMessage.

    While you can use a message only window if you don't have a window in your application, you can also use PostThreadMessage to post messages to a different thread, even if that thread is in a completely different process.

    So you have a message queue available to you.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Edited by Darran Rowe Friday, September 13, 2019 4:38 AM
    • Marked as answer by Geng88 Monday, September 16, 2019 3:33 AM
    Friday, September 13, 2019 4:37 AM
  • Hello Darran,

    Thanks for the advice but it seem like the datatype of the message to be transferred is limited to UINT only. I'm struggling to fit it into my application. My previous message queue application is something like below:

    //Define Message Structure
    typedef struct
    {
    UCHAR command;
    UCHAR state;
    BYTE  Data[8][8];
    } Cal_Data_t;

    //Main Program

    Cal_Data_t calDataToStation;

    MSGQUEUEOPTIONS msgQ_Opts = {sizeof(MSGQUEUEOPTIONS), MSGQUEUE_NOPRECOMMIT | MSGQUEUE_ALLOW_BROKEN, 50, MSGQ_SIZE, FALSE};

    HANDLE hMsgQ = CreateMsgQueue(L"EventMsg", &msgQ_Opts );

    // Send calDataToStation to another application after some data assignment

    WriteMsgQueue( hMsgQ, &calDataToStation, sizeof(Cal_Data_t), INFINITE, MSGQUEUE_MSGALERT );

    It would be inefficient if the desktop message queue method is applied to perform the above task.

    Besides, I found out that there is another method called MSMQMessage. But I notice that Microsoft is no longer updating the content. Is MSMQ method recommended? 

    Hope to hear from you soon.

    Thank you.

    Regards,

    Geng88

     

    Wednesday, September 18, 2019 9:25 AM
  • Perhaps the WM_COPYDATA message would be useful.

    Wednesday, September 18, 2019 9:42 AM
  • Desktop windows applications can also use a variety of methods for interprocess commuications.

    There is a brief summary at https://docs.microsoft.com/en-gb/windows/win32/ipc/interprocess-communications

    Wednesday, September 18, 2019 10:18 AM
  • You have to be careful since you are probably not comparing things correctly here.

    First of all, remember that the Windows CE message queue is a wrapper around something. This means that it will automate some things, like marshaling (copying) data between processes.

    Even if Windows CE has a shared address space, desktop Windows has separate address spaces for each process so you must use some form of inter process communication to copy the data from one process to another regardless.

    Since user window messages don't marshal data, you would have to do this manually. You can use something like:

    #include <Windows.h>
    
    constexpr int mystruct_identifier = 0x0400; //randomly chosen value to identify that you have send data of type mystruct
    constexpr UINT mycustom_message = WM_USER + 100; //identifier chosen in advance to identify this message
    
    struct mystruct
    {
    	//structure members
    };
    
    void send_data(mystruct *data, HWND target_window, HWND source_window)
    {
    	COPYDATASTRUCT to_send{};
    
    	to_send.dwData = mystruct_identifier; //an identifier for the data that you send
    	to_send.cbData = sizeof(mystruct); //the size of the data to send
    	to_send.lpData = data; //the actual data
    
    	PostMessage(target_window, WM_COPYDATA, reinterpret_cast<WPARAM>(source_window), reinterpret_cast<LPARAM>(&to_send));
    	//because this is a custom message the parameters are what i chose them to be
    	//in this case WPARAM is unused and LPARAM is the identifier of the data sent using WM_COPYDATA
    	PostMessage(target_window, mycustom_message, 0, mystruct_identifier);
    }

    on the send side. The receive side would basically copy the data into a permanent buffer for the WM_COPYDATA message handler and then the handler for the custom message will process the data you copied to the separate process.

    The more that I read, the more I believe that the Windows CE message queue is some form of named pipe though. So maybe you would want to look into Named Pipes instead.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Edited by Darran Rowe Wednesday, September 18, 2019 9:19 PM
    Wednesday, September 18, 2019 9:03 PM
  • PostMessage(target_window, WM_COPYDATA, reinterpret_cast<WPARAM>(source_window), reinterpret_cast<LPARAM>(&to_send));

    Apologies in advance for nitpicking -- I think that WM_COPYDATA must be used with SendMessage, not PostMessage.

    Perhaps this is tangential, but why would a separate custom message be needed on the receive side since the message identifier was stored in the COPYDATASTRUCT?

    • Edited by RLWA32 Wednesday, September 18, 2019 10:03 PM
    Wednesday, September 18, 2019 9:56 PM
  • See my signature. :3

    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Thursday, September 19, 2019 12:03 AM
  • If you want a more serious answer. When it comes to Windows messages, I tend to assume a PostMessage over send. So if I use something that I haven't touched in ages and forget things, then these mistakes happen.

    The usage of a custom message was simply to make the OP think a little bit. Part of that did come about from some weird system requirements that I once had to deal with where it turned out to be easier to store the marshaled data and then use custom messages to work on it via messages though.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Thursday, September 19, 2019 12:24 AM