Event "OnReciveData" is not triggered in the thread

[sergey-zheleztsov]

Hello, MHumm!
If an instance of TCommPortDriver is created in a separate thread, the data arrival event in the port buffer is not triggered, apparently due to the fact that the window function is used for verification. For normal operation, I had to add a system message processing cycle to the Execute procedure

procedure TMeterThread.Execute;
...
Cprt := TCommPortDriver.Create( nil );
Cprt.BaudRate := br9600;
Cprt.StopBits := sb1BITS;
Cprt.Parity := ptNONE;
Cprt.DataBits := db8BITS;
Cprt.PollingDelay := 50;
Cprt.PacketSize := -1; 
Cprt.Port := TPortNumber( PrtNm.Substring( 3 ).ToInteger );   // Number in the "\\.\COMn"
Cprt.OnReceiveData := CPRxChar;   // <- OnReceiveData - does not work in TMeterThread :((
Cprt.OnError := CommPortError;
...
// But if you add the lines below, the OnReceiveData event starts
case MsgWaitForMultipleObjectsEx( 0, nil^, 50, QS_ALLINPUT, 0 ) of
      WAIT_OBJECT_0:
        begin
          while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
          begin
            if Msg.message = WM_QUIT then
              Exit;
            TranslateMessage(Msg);
            DispatchMessage(Msg);
          end;
        end;
      WAIT_FAILED:
        Break;
    end;
...
end;   // of Execute

Is there any way to take this into account in a future release?

[MHumm]

Maybe it can get included in a future version, but only if I fully understand it and its implications. As far as I remember (I'm not the original author of this, I just made some improvements and fixed some bugs) the whole component does not use any threads.

[MHumm]

Ah, the key is that the component uses a timer for polling the com-port to find out if any data arrived. That timer works using WM_TIMER messages, as regular Windows timer do. And if you run it in a separate thread, that separate thread needs to have amessage processing mechanism (a VCL or Windows FMX application has such a message processing look burried into the VCL and FMX and that works like Application.ProcessMessages).

So the question here would be whether the component should provide a message loop method working on the handle of the current thread, so anybody wanting to use it in a thread can call this method in his execute method.

One might construct the message handling like in your case or something which uses GetMessage so it automatically sleeps when there's nothing to do. That would need sending a special message when the thread is terminated to trigger GetMessage there and react on that by quitting the message loop. I just don't know MsgWaitForMultipleObjectsEx yet.