Button Events vs. Timer Callback

[Mike]

Greetings,

We have a circumstance where we have a series of individual buttons,
whose functionality works. This consists of sending a message to an
RS-232 port, and awaiting a reply asynchronously.

When a button is clicked, the message is sent, and we await bytes that
are received via a delegated event. This all works as expected when we
click the buttons individually.

Now we have a circumstance where we would like to organize a sequence
of these commands, timed according to a threaded timer. During the
timer callback, we'll BeginInvoke() and subsequently call each of the
button event handlers one after the other.

The protocol has a built-in timeout feature, also a timer callback,
which effectively terminates the attempted receipt of response.

Incidentally, this may be important as well, our "protocol" of sent and
received data is such that we await the response received from one sent
message and set an AutoResetEvent when it is fully received.

As it relates to the callback, we start with the first call, we have
verified we first sent the message, and then (by what we think is how
the design ought to work) we should await an asynchronous response from
the RS-232 port.

This does not seem to be happening, so we're wondering whether there is
some sort of a timer or threading issue blocking us from actually
receiving this response. We are fairly certain that we are also
changing the timeout timer, which we are also not seeing any evidence
of.

This is very tricky because it is timers, threads, and synchronizing
this sequence of events. So we're hopeful that someone can offer some
of their insights in these areas.

Best regards,
Michael Powell

 

[Mike]

Stepping back for a moment... We'll have to read up on Timers and their
Callbacks, because it seems that a Timer callback is not necessarily
kosher with event handlers (i.e. as it relates to a test timer
operating in conjunction with a serial data received event handler).

I'm sure there's probably a solution in between there somewhere. In
essence, ideally we'd like for the Timer callback to work in
conjunction with the subsequent event handlers, but since that doesn't
appear to be happening, we need to find a balance somewhere in between.

There are at least a couple of options as I see it (more design related
than anything else):

1) We can separate the test timer into "steps" and execute each step
successively on each callback. This would call down to the serial port
synchronously, which is working, but which is horribly slow, especially
for large quantities of data. Which is also blocking the main
application thread while it is running (not a good thing).

**** Or ****

2) Find some alternative to the timer callback which is happy in
conjunction with serial port asynchronous data read events.

Mainly thinking out loud at this point...