Help required: Threading and events/delegates

[Kelly Adams]

I am stumped at the moment by something, and the searching I've done
hasn't led to a clear answer. Here is what I want to do:

I have two threads: thread A and thread B. I want Thread B to raise
an event that will be handled within the context of thread A. By
default, an event raised by Thread B will be processed within thread
B's context. That's not what I want.

What is the best / simplest way to accomplish this? I've looked at
using delegates and BeginInvoke, but the way I read it that creates
yet another thread using the thread pool- I want to hand the event to
a specific, already running thread.

Thoughts?

Kelly Adams

[Eric Sabine]

This might help.

http://msdn.microsoft.com/library/de...isualBasic.asp

hth
Eric
"Kelly Adams" <ke***********@yahoo.com> wrote in message
news:3j********************************@4ax.com...

I am stumped at the moment by something, and the searching I've done
hasn't led to a clear answer. Here is what I want to do:

I have two threads: thread A and thread B. I want Thread B to raise
an event that will be handled within the context of thread A. By
default, an event raised by Thread B will be processed within thread
B's context. That's not what I want.

What is the best / simplest way to accomplish this? I've looked at
using delegates and BeginInvoke, but the way I read it that creates
yet another thread using the thread pool- I want to hand the event to
a specific, already running thread.

Thoughts?

Kelly Adams

[CJ Taylor]

This has come up before and I didn't give a great answer, but I think I have
a way to do it now.

Here we go.

On your Thread A class create an object of type
System.windows.forms.control, we only want it for one thing, and that is its
Invoke method.

Create the control AFTER you have started the thread (i.e. call the
constructor in your entry point of the thread).

Use an event to attach between Thread A and Thread B

Thread B raises an event, Thread A grabs this event, the context is still
within thread B

Use your created control's Invoke method to invoke it on the thread it was
created (Thread A) and invoke whatever method you wish.

HTH,
CJ
"Kelly Adams" <ke***********@yahoo.com> wrote in message
news:3j********************************@4ax.com...

I am stumped at the moment by something, and the searching I've done
hasn't led to a clear answer. Here is what I want to do:

I have two threads: thread A and thread B. I want Thread B to raise
an event that will be handled within the context of thread A. By
default, an event raised by Thread B will be processed within thread
B's context. That's not what I want.

What is the best / simplest way to accomplish this? I've looked at
using delegates and BeginInvoke, but the way I read it that creates
yet another thread using the thread pool- I want to hand the event to
a specific, already running thread.

Thoughts?

Kelly Adams

[Kelly Adams]

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote:

This has come up before and I didn't give a great answer, but I think I have
a way to do it now.

Here we go.

On your Thread A class create an object of type
System.windows.forms.control, we only want it for one thing, and that is its
Invoke method.

Create the control AFTER you have started the thread (i.e. call the
constructor in your entry point of the thread).

Use an event to attach between Thread A and Thread B

Thread B raises an event, Thread A grabs this event, the context is still
within thread B

Use your created control's Invoke method to invoke it on the thread it was
created (Thread A) and invoke whatever method you wish.

Hmmm: interesting. It seems a bit "roundabout", but it might just do
the trick. I'll give it a go in my little test routine: thanks for
the idea!

[Kelly Adams]

"Eric Sabine" <mopar41@___ho_y_tmail.ScPoAmM> wrote:

This might help.

http://msdn.microsoft.com/library/de...isualBasic.asp

hth
Eric

Eric, I've looked over that set of documentation before. Perhaps I am
missing something, but the only reference to passing values between
threads that I can see in that material is here:
http://msdn.microsoft.com/library/de...procedures.asp

And guess what? It uses an event raised by the worker thread to
notify the calling thread that the worker thread has finished some
task...but that event would be executed within the context of the
worker thread. Write a small piece of sample code as they have
described it, with console.writelines to display the thread ID
executing at each stage of execution and you will see what I mean.

Is there some further documentation in this material that you think
answers my question?

[CJ Taylor]

I don't know how much more direct you want to get =) Invoke is the only
control I know that does the plumbing between crossing thread contexts. I
suppose you could write that yourself through the API, but then again, who
wants to deal with unmanaged right now.
"Kelly Adams" <ke***********@yahoo.com> wrote in message
news:49********************************@4ax.com...

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote:

This has come up before and I didn't give a great answer, but I think I havea way to do it now.

Here we go.

On your Thread A class create an object of type
System.windows.forms.control, we only want it for one thing, and that is itsInvoke method.

Create the control AFTER you have started the thread (i.e. call the
constructor in your entry point of the thread).

Use an event to attach between Thread A and Thread B

Thread B raises an event, Thread A grabs this event, the context is still
within thread B

Use your created control's Invoke method to invoke it on the thread it wascreated (Thread A) and invoke whatever method you wish.

Hmmm: interesting. It seems a bit "roundabout", but it might just do
the trick. I'll give it a go in my little test routine: thanks for
the idea!

[CJ Taylor]

excuse me... Invoke is the only method... Control is the only class I know
that contains it...
"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
news:Oo**************@TK2MSFTNGP10.phx.gbl...

I don't know how much more direct you want to get =) Invoke is the only
control I know that does the plumbing between crossing thread contexts. I
suppose you could write that yourself through the API, but then again, who
wants to deal with unmanaged right now.
"Kelly Adams" <ke***********@yahoo.com> wrote in message
news:49********************************@4ax.com...

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote:

This has come up before and I didn't give a great answer, but I think I havea way to do it now.

Here we go.

On your Thread A class create an object of type
System.windows.forms.control, we only want it for one thing, and that is

its

Invoke method.

Create the control AFTER you have started the thread (i.e. call the
constructor in your entry point of the thread).

Use an event to attach between Thread A and Thread B

Thread B raises an event, Thread A grabs this event, the context is

stillwithin thread B

Use your created control's Invoke method to invoke it on the thread it

wascreated (Thread A) and invoke whatever method you wish.

Hmmm: interesting. It seems a bit "roundabout", but it might just do
the trick. I'll give it a go in my little test routine: thanks for
the idea!

[Kelly Adams]

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote:

I don't know how much more direct you want to get =) Invoke is the only
control I know that does the plumbing between crossing thread contexts. I
suppose you could write that yourself through the API, but then again, who
wants to deal with unmanaged right now.

I'm not disagreeing with you on that point. What is problematic (and
roundabout) for me is that my application has no user interface. Its
a service (currently I'm debugging it as a console application).

To make your approach work, I have to figure out how to instantiate a
control properly in a non-UI application- it needs a window handle
(discovered that right away). I have to add the System.Windows.Forms
class, and instantiate a form I guess, and add the control to that
form...at run time, the compiler still complains about not having a
window handle...I must be missing something here, but I assume its
doable.

That all said, I have to assume that there is some way to do this
(make an event execute in the context of a thread other than the one
generating the event) without using a form control. It seems like it
*should* be easy to do...

[Tom Shelton]

In article <p9********************************@4ax.com>, Kelly Adams wrote:

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote:

I don't know how much more direct you want to get =) Invoke is the only
control I know that does the plumbing between crossing thread contexts. I
suppose you could write that yourself through the API, but then again, who
wants to deal with unmanaged right now.

I'm not disagreeing with you on that point. What is problematic (and
roundabout) for me is that my application has no user interface. Its
a service (currently I'm debugging it as a console application).

To make your approach work, I have to figure out how to instantiate a
control properly in a non-UI application- it needs a window handle
(discovered that right away). I have to add the System.Windows.Forms
class, and instantiate a form I guess, and add the control to that
form...at run time, the compiler still complains about not having a
window handle...I must be missing something here, but I assume its
doable.

Use the System.Windows.Forms.NativeWindow class to generate a window
handle.

--
Tom Shelton [MVP]

[CJ Taylor]

Thank you tom =)

"Tom Shelton" <to*@mtogden.com> wrote in message
news:uS**************@TK2MSFTNGP10.phx.gbl...

In article <p9********************************@4ax.com>, Kelly Adams

wrote:

"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote:

I don't know how much more direct you want to get =) Invoke is the only
control I know that does the plumbing between crossing thread contexts. Isuppose you could write that yourself through the API, but then again, whowants to deal with unmanaged right now.

I'm not disagreeing with you on that point. What is problematic (and
roundabout) for me is that my application has no user interface. Its
a service (currently I'm debugging it as a console application).

To make your approach work, I have to figure out how to instantiate a
control properly in a non-UI application- it needs a window handle
(discovered that right away). I have to add the System.Windows.Forms
class, and instantiate a form I guess, and add the control to that
form...at run time, the compiler still complains about not having a
window handle...I must be missing something here, but I assume its
doable.

Use the System.Windows.Forms.NativeWindow class to generate a window
handle.

--
Tom Shelton [MVP]