Re: best way to receive 'callbacks' in a GUI from other threads

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Emma,

If the mechanism you're using implies asynchronous behavior then I
would continue doing what you're doing. Most people assume that
callbacks are invoked from the thread running the asynchronous
operation. This is especially the case if you've used the
BeginSomeOperation/EndSomeOperation pattern.

Another option is to pass a reference a form or control to your worker
class and let it do the marshaling for you. Microsoft used a similar
pattern for the System.Timers.Timer object. In that case they created
a SynchronizingObject property that the Timer uses to automatically
marshal the Elapsed event. If SynchronizingObject is null then the
Elapsed event is executed on a ThreadPool thread. I find that to be a
rather elegant pattern especially if the worker class uses events to
report progress.

Brian

emma_middlebrook@xxxxxxxxxxx wrote:
Hi

Advice needed about what's the best in the following situation.

In essence, I have a GUI that needs to detail time taken to do jobs
that execute in their own thread.

Currently, the GUI thread instantiates a class that wraps a job,
handing it a callback (delegate) to call once the job has finished. On
callback, always on a different thread than the GUI thread,
InvokeRequired is tested (and is always true), and the GUI is updated
via Invoke.

Is this standard and best? Or do people out there do something
different? I'm just concerned about the GUI class having to do a
thread-related test. It seems out of place: it shouldn't have to know
that other threads are involved so is there some kind of standard way
to hide this away?

Thanks and any help appreciated!

Emma.

.

Relevant Pages

  • Re: CoBOL moved to OO
    ... of a list of file names' by using the Windows GUI and the keyboard alone ... > Alternatively write the collection elements to your text file with a Callback (see ... > invoke FileNames2 "new" returning os-Filenames ...
    (comp.lang.cobol)
  • best way to receive callbacks in a GUI from other threads
    ... I have a GUI that needs to detail time taken to do jobs ... handing it a callback to call once the job has finished. ... via Invoke. ... Is this standard and best? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: CoBOL moved to OO
    ... Alternatively write the collection elements to your text file with a Callback (see ... invoke FileNames2 "new" returning os-Filenames ... Procedure Division returning lnk-self. ... 01 os-CallbackDefaultSort object reference value null. ...
    (comp.lang.cobol)
  • Re: Async callback vs events vs ?
    ... This seems to make life complicated and dangerous since there is still a lot I need to do with the information returned including updating the GUI, calling more methods, ... ... The only thing you probably need to really fix is the lack of a call to Control.Invokein your event handler. ... just pass your delegate instance as the state object to the call to BeginInvoke, and then retrieve that from the IAsyncResult.AsyncState property. ... The call to Control.Invoke() does the exact same check, and will simply invoke the delegate directly if InvokeRequired is false. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Async callback vs events vs ?
    ... I suppose I could use the IAsyncResult to pack this information in but - and here is where I lose the plot - all of this is still running under the thread from the threadpool as far as i can tell. ... This seems to make life complicated and dangerous since there is still a lot I need to do with the information returned including updating the GUI, calling more methods, ... ... -- Related to the above, there's no need to check the EndInvokeCalled property; your callback will only be called once per invocation, and you should write the code to only call EndInvokein that callback. ... The call to Control.Invoke() does the exact same check, and will simply invoke the delegate directly if InvokeRequired is false. ...
    (microsoft.public.dotnet.languages.csharp)