Re: [Dev-C++] how to update data constantly?

[Per W. <pw...@ia...>]

The RS232 API in Windows supports event-driven processing. You can get an
event when a receive buffer is full, a specific 'match' character is
received or there has been a timeout between two characters.

A match character is maningful to catch a line-break in ASCII protocols,
or the end-of-message byte in a binary protocol.

You normally don't let the RS232 thread process characters one at a time,
so you normally don't generate an update event every character. When
implementing a chat, the RS232 code will normally trig on the pause
between individual characters, resulting in a character-at-a-time update
of the GUI. If the user pastes a large block of text, the serial driver
will instead generate events based on serial buffer size with an optional
time-out event after the paste. Is the receive buffer large enough, the
paste will only result in a single timeout event, i.e. a single GUI
update.

A computer-driven communication will on the other hand trig on buffer-full
events or the end-of-message event from the filter character, and allowing
updates of the GUI a message at a time or a full serial buffer at a time.
For this kind of communication, the GUI would normally not display actual
data, but instead transfer statistics, i.e. # of packets, # of bytes, # of
resends or similar.

In the end, there will normally not be a problem with a dying GUI
overloaded by more and more cached events, since the amount of events
will normally be limited by the RS232 configuration. A correct
implementation of the GUI would also make use of PeekMessage() whenever
it receives an update event but before it performs the updating. This
allows multiple pending update events to only result in a single screen
redraw.

A message-based solution will consume zero processing power when the
serial channel is idle, and will generate redraw load corresponding to
buffer size, timeout and end-of-message intervals when data is arriving.

/pwm

On Thu, 6 Dec 2007, Chris Miller wrote:

> On Dec 6, 2007 2:41 AM, Per Westermark <pw...@ia...> wrote:
> > One alternative is to let the RS232 thread send messages to the GUI
> > thread. Either with the serial data, or just as information that there are
> > serial data available.
> >
> > /pwm
>
> I would like to note that this does have a significant drawback.
>
> If you have to update the GUI every time something happens, it has a
> tendency to lag in a big way.
>
> You can alleviate this by only updating every X updates, however, this
> adds a problem of constantly checking whether or not the update
> threshold has been reached.  It's far simpler to use the mutex
> approach, even though it is slightly more difficult to implement and
> harder to understand (if you're not familiar with it).
>
> Once I tried having the working thread update the GUI in Java....
> locked up the whole GUI during operation, so if you wanted to kill it
> you'd have to kill the running JVM - not fun!
>
> --
> Registered Linux Addict #431495
> http://profile.xfire.com/mrstalinman
> John 3:16!
> If Microsoft is the Wal*Mart of the Software World, then Linux is the Home Depot
>