Hi Jit Sing;

  For the Message.ReturnValue = ? setting, you can influence what the O/S and/or PBVM will do when control is passed back to the Message Queue handler. The value and behaviour of the Return Value is totally dependent on the O/S message being processed. You can read more about this on MSDN: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getmessage

   Also, when O/S messages arrive at a PB App they fire an event. However, there are various message queues and not just the one main App queue. An example of this is the DW Control and/or DataStore that have their own MQ's. In the case of the DC/DS, the PBVM (runtime) routes messages from the main App message Queue into the DC / DS MQ where they are processed by only the DC/DS MQ handler in the PBVM ... hence the PBM_DWNxxxxx specialized events. The PBM_DWNxxxxx events are only occurring because of the DC/DS MQ handler. The DC/DS object classes often do not see the main App message queue. However, when any O/S message is processed by an object class, it has the option to chain the message back on to the MQ it got it from so that other object classes can also detect it. The PBVM normally does this by default. However, when you state message.processed = 1 in your code, you are asking the MQ handler to not chain the message back on to the MQ it got it from so that other classes can see it.

   If Message.Porcessed = 0 and the message is then "chained", the Message.Return value is available to the next object class (or O/S process) that see the MQ next. They can then determine what they should do if the Message.Return Value is not Zero. Basically, a way of sending a "status code" down the MQ processing line of execution.

  Note: the DC/DS MQ does chaining but, never chains the original message back onto the main App's MQ. Once the message is routed to the DC/DS MQ, it chains along until the end of the DS/DS MQ is reached. That is why many non-DC/DS object classes never see DS/DC messages.

Regards ... Chris