[Prev][Next][Index][Thread]

Re: help with DUIM application

In article <mnC15.49206$Ft1.2730522@typhoon.ne.mediaone.net>,
  "Scott McKay" <swm@mediaone.net> wrote:

> If I were doing it, I would use two threads.  Because of some
> Windows idiosyncracies, you are best off using the initial thread
> to manage your user interface, and start a different thread to
> manage the serial input.  Use the threads library, and have the
> first thread await some sort of signal from the serial input thread.
>
> You could look at the Life example to see how a multi-threaded
> DUIM app works.  The UI thread draws the display and handles
> inout events, such as the user selecting something from a menu.
> The "compute" thread (which corresponds to your serial input
> thread) computes each new generation and notifies the UI thread
> when a new generation is fully computed.
>
>

Thanks for the ideas Scott and Jason.  I looked at the Life example a
bit.  If I understand it correctly, the notifications going on in the
Life example are in the opposite direction of what I would want, and the
logic and display threads in the Life example are VERY tightly coupled.
I mean that the logic thread actually is involved in drawing and knows
about the slots in the main frame.  I'd rather avoid that.

It occurs to me that this is really just another example of one of the
most common design patterns:  the subject/observer or publish/subscribe
pattern.  The serial-io thread is a data producer, which I think of as a
subject.  The display thread is an observer.  So, following the design
pattern, I think the display thread (i.e. the main frame) would need a
Notify() method (in GOF terminology).  It would also register with the
serial-io thread at startup.  When the serial-io thread has new data, it
would call the Notify() method for the display thread.  What I like
about thinking about the problem in this way is that by following this
pattern I would have a more general solution to the problem.  For
example, it would be possible to have multiple objects and/or threads
register with the data producer.  The data producer could then call the
Notify() methods for all observers when it has new data.

Now how this fits into the suggestions given already...   Is the
call-in-frame method the equivalent of the Notify() method?  I'll have
to think about that some more.

Thanks again for the ideas.


Sent via Deja.com http://www.deja.com/
Before you buy.
Follow-Ups: References: