That's exactly what I have, but when the event is fired, and I breakpoint the
event code, visual studio shows it's still running in the worker thread. Is
VS being a little misleading in it's thread monitoring?

One thing I want to be clear about in your example: the OnHelloUserDone
method is actually called on the worker thread, correct?

"Ken Slovak - [MVP - Outlook]" wrote:

Something like this for the delegate events:

// In the class for the background worker:

internal delegate void HelloUserDoneEventHandler(object sender,
EventArgs e);

internal event HelloUserDoneEventHandler HelloUserDone;

// make a call in the code that handles worker done to OnHelloUserDone()

protected virtual void OnHelloUserDone(EventArgs e)
{

HelloUserDoneEventHandler handler = HelloUserDone;
if (handler != null)
{
// Invokes the delegate.
handler(this, e);
}
}

// in the code in the main class or wherever

private void HelloUser(object sender, EventArgs e)
{
if (e.Result != null)
{
// event fired, work done
}
}

Of course in the main code you'd need to instantiate the HelloUser event
handler, something like this, where myWorker is the class that has the
background worker:

_worker.HelloUserDone += new myWorker.HelloUserDoneEventHandler(HelloUser);

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Dorian" wrote in message
...
Using a struct for the MailItem information makes sense, and if I am able
to,
using a delegate event handler to return to the main thread makes sense.
In
my previous experiences I've used the Invoke method of the control that
the
main thread is being run on. Unfortunately I don't use any forms in the my
addin. Any hints on how to invoke an event on a main thread without having
access to Control.Invoke?