On Mon, 26 Mar 2007 19:58:46 -0700, <Petedwrote:
[...]
i want to have a background worker thread on a form that once a minute
sends a command to retrieve the current time from this ip device then
update it into the form display.
Whats the best way to handle gui update from a worker thread ?
See Invoke and BeginInvoke. You can invoke a delegate on the main GUI
thread, by calling one of those methods from the worker thread. The
delegate would be passed whatever data you need for the update, and would
update the GUI as necessary.
how can i call thie method in the IPdevice class from the worker
thread without casuing a conflict when the same method is called from
a button click on the form ?
It's not clear from your post what functionality you actually need.
However, assuming you have a single class (IPdevice) that handles i/o with
your device, but you have multiple users of that class, I see at least a
couple of options that might work.
One is to simply synchronize access to the class. Assuming your i/o is
strictly of the "query/response" sort, and responses occur in a
nearly-immediate manner, this would probably work fine (you'd wind up with
threads waiting not only on their own queries, but those of other threads,
so if the queries aren't nearly-immediate the delays would be more
noticeable). You would take a lock at the beginning of any
"query/response" sequence. This would allow your worker thread and main
thread to both use the IPdevice while ensuring that only one at a time is
actually communicating with your device.
Another option would be to create an i/o queue that stores the query and a
delegate to be called when the response is received. This would still
need to be synchronized, but it would allow the client threads (the main
GUI thread and the worker thread) to do other things while waiting for the
i/o to complete. It doesn't sound like this would be required in your
case, but it's something to consider if my impression of your situation is
incorrect. (Note that this option is very similar to the already-existing
paradigm provided by the network i/o classes in the "async with callback"
methods...you'd have to implement your own layer on top of that, to deal
with the fact that you have different clients of the IPdevice class, but
you can look at the .NET version for an idea of how this would work)
These are not necessarily the only solutions...they just happen to be what
came to mind for me first.
Pete
