CODEWITHSUNDEEP
delphidelphi-xe
Jan Hakl
Jan Hakl

Reputation: 75

What happens when ShowMessage is called?

I am working on the project where I communicate with another device over COM port. For incoming data I am using VaComm1RXchar event, there I store the message into the array and increment msgIndex which represents number of messages.

Then I call the function where I work with this message.

Inside this function is this timeout cycle where I wait for this message:

  while MsgIndex < 1 do
  begin
  stop := GetTickCount;
  if (stop - start)> timeout then
    begin

      MessageBox(0, 'Timeout komunikace !', 'Komunikace', MB_OK);
      exit(false);
    end;
    sleep(10);
  end;

The strange thing for me is that, when have it like this above then it always end with timeout. But when I put on there before this while cycle a ShowMessage('Waiting') then It works correcly.

Does anyone know what can caused this and how can I solve it? Thanks in advance!

Upvotes: 2

Views: 1086

Answers (2)

J...
J...

Reputation: 31443

We can deduce that the VaComm1RXchar event is a synchronous event and that by blocking your program in a loop you are preventing the normal message processing that would allow that event to execute.

Showing a modal dialog box, on the other hand, passes message handling to that dialog so the message queue is properly serviced and your Rx events and handled normally.

You can be certain this is the case if this also works (please never write code like this - it's just to prove the point):

while MsgIndex < 1 do begin
  stop := GetTickCount;
  if (stop - start)> timeout then begin    
    MessageBox(0, 'Timeout komunikace !', 'Komunikace', MB_OK);
    exit(false);
  end;
  Application.ProcessMessages; // service the message queue so that
  sleep(10);                   // your Rx event can be handled
end;

If there is a lesson here it is that RS-232 communication really needs to be done on a background thread. Most all implementations of "some chars have been received" events lead to dreadful code for the very reason you are discovering. Your main thread needs to be free to process the message that characters have been received but, at the same time, you must have some parallel process that is waiting for those received characters to complete a cogent instruction. There does not exist a sensible solution in an event-driven program to both manage the user interface and the communication port at the same time on one thread.

A set of components like AsyncPro**, for example, wrap this functionality into data packets where synchronous events are used but where the components manage start and end string (or bytes) detection for you on a worker thread. This removes one level of polling from the main thread (ie: you always get an event when a complete data packet has arrived, not a partial one). Alternatively, you can move the communication work to a custom thread and manage this yourself.

In either case, this is only partly a solution, of course, since you still cannot stick to writing long procedural methods in synchronous event handlers that require waiting for com traffic. The second level of polling, which is managing a sequence of complete instructions, will still have you needing to pump the message queue if your single procedure needs to react to a sequence of more than one comport instruction. What you also need to think about is breaking up your long methods into shorter pieces, each in response to specific device messages.

Alternatively, for heavily procedural process automation, it is also often a good idea to move that work to a background thread as well. This way your worker threads can block on synchronization objects (or poll in busy loops for status updates) while they wait for events from hardware. One thread can manage low level comport traffic, parsing and relaying those commands or data packets, while a second thread can manage the higher level process which is handling the sequence of complete comport instructions that make up your larger process. The main thread should primarily only be responsible for marshalling these messages between the workers, not doing any of the waiting itself.

See also : I do not understand what Application.ProcessMessages in Delphi is doing

** VAComm may also support something like this, I don't know. The API and documentation are not publicly available from TMS for ASync32 so you'll need to consult your local documentation.

Upvotes: 6

David Heffernan
David Heffernan

Reputation: 613412

What happens is that a modal message loop executes when the dialog is showing. That this message loop changes behaviour for you indicates that your communications with the device require the presence of a message loop.

So the solution for you is to service the message queue. A call to Application.ProcessMessages in your loop will do that, but also creates other problems. Like making your UI become re-entrant.

Without knowing more about your program, I cannot offer more detailed advice as to how you should solve this problem.

Upvotes: 0

Related Questions