Re: [Dev-C++] how to update data constantly? (multi-threaded programming, RS232)

[Jessica C. <jes...@gm...>]

How to implement the "let the RS232 thread send message to the GUI thread"
for updating the GUI?
Can you give us a pseudo code for it?
I guess you will formulate a message in RS232 thread, then let the GUI
thread to get this message by PeekMessage().  ??

I agree that "you normally don't generate an update event every character".
So I am thinking to generate an update event every message.  I mean, after I
get the whole message (including end-of message character), I am thinking to
give out an indication to GUI that we got an full message.  What shall I do
for it? Do I need to set a flag here to give out this kind indication? OR
win32 API provide us functions to do that?

If I want to use RS232 thread to receive data, and GUI thread display data.
Do I need create two buffers in RS232 thread?
Back-end buffer is used to receive data, while front-end buffer is used to
provide data to the GUI thread.
What is the basic (classic) design for this problem?

===============
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.

On Dec 7, 2007 6:56 AM, Per Westermark <pw...@ia...> wrote:

> 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
> >
>
>