On Tue, 18 Nov 2008 09:09:55 -0800 (PST),
st*******@gmail.com wrote:
>Basically what I have is a form with a graph on it which graphs data
that I'm reading from a USB device at 100 Hz (every 10ms). I have a
thread reading and parsing the data from the USB, but when it comes
time to draw that data on the graph the work is handled on the main UI
thread through a callback delegate since the form owns the graph
control. Is there a way I can have a separate thread own the graph
control and handle the drawing so that the rest of the UI is not
affected?
Having followed the thread these thoughts come to mind. The issue
seems to be the side effects of trying to maintain the data display in
real-time. I recently ran into a similar issue writing a CAT
controller/monitor for a device with minimal documentation.
http://www.subdevo.com/FT897DCAT/
The device has thirteen buttons, seven rotary controls (three
concentric plus one), six LEDs and a ~2x3 inch LCD screen. All the
controls are multifunction. One of the things the LCD display can do
is act as a spectrum scope. This gives an idea of how much and the
kind of information the UI might be expected to display.
Each request/response pair exchanged describes part of the current or
desired state of the device. The state information is sent to the
device using five byte requests. Depending upon the request the
response may be zero to five bytes with a RTT of up to ~5 ms. Multiple
requests are needed to fully describe the device's state. At any time
the polling may be interrupted to send a request to the device to
change state.
Trying to update the numerous UI controls in real-time resulted in a
sluggish UI. My solution was to create an type which represents the
device's state to the UI. It is a composite object that essentially is
a middle tier between the device and UI. A worker thread (the
controller thread) runs a loop that manages various custom thread
objects. The callbacks go to the worker thread not the UI thread. Each
polled response partially updates the state.
This scheme lets the BL/TL/device wrappers to be packaged UI-free. A
timer in the UI fires periodically to update numerous UI controls with
data read from properties the clean, simple interface the state object
presents to the UI.. Changes to the device state are made from the UI
by changing state object's properties.
regards
A.G.