Is this Application.Run () correct?

[jm]

This works, but I don't know why.

static void Main()
{
// Queue the task.
ThreadPool.Queu eUserWorkItem(n ew WaitCallback(Th readProc),new
Form1());
Application.Run ();
}

static void ThreadProc(Obje ct stateInfo)
{
// When no state object was passed to QueueUserWorkIt em, so
// stateInfo is null.
Form1 f1 = (Form1) stateInfo; //the passed form
f1.notifyIcon1. Icon = new
Icon(System.Ref lection.Assembl y.GetExecutingA ssembly().GetMa nifestResourceS tream("Listener 1.connecting.ic o"));
clsListening myLis = new clsListening(f1 );
myLis.StartList ening(f1);
}

I had to do it this way because I could not pass "this" to the class
because ThreadProc was static and new WaitCallBack(Th readProc)
required a static method.

What I don't understand is how the thread part can run before the
Application.Run () can. How can it be executing code before it is
running?

Also, let me see if I am correct. The ThreadPool.Queu eUserWorkItem
sends the an instantiated new Form1() to the ThreadProc. stateInfo
becomes that object. I then assign that object to the type Form1 f1
(cast to Form1 so I know what kind of object (object stateInfo) is)
and then I get to work with my form.

It works, but am I correct here?

Thank you for helping me.

[Jon Skeet [C# MVP]]

jm <jo************ *@yahoo.com> wrote:

This works, but I don't know why.

static void Main()
{
// Queue the task.
ThreadPool.Queu eUserWorkItem(n ew WaitCallback(Th readProc),new
Form1());
Application.Run ();
}

static void ThreadProc(Obje ct stateInfo)
{
// When no state object was passed to QueueUserWorkIt em, so
// stateInfo is null.
Form1 f1 = (Form1) stateInfo; //the passed form
f1.notifyIcon1. Icon = new
Icon(System.Ref lection.Assembl y.GetExecutingA ssembly().GetMa nifestRes
ourceStream("Li stener1.connect ing.ico"));
clsListening myLis = new clsListening(f1 );
myLis.StartList ening(f1);
}

I had to do it this way because I could not pass "this" to the class
because ThreadProc was static and new WaitCallBack(Th readProc)
required a static method.

What I don't understand is how the thread part can run before the
Application.Run () can. How can it be executing code before it is
running?
The thread pool runs separately of the message queue. Application.Run
just starts a message pump for the given form, and waits until it
closes down.
Also, let me see if I am correct. The ThreadPool.Queu eUserWorkItem
sends the an instantiated new Form1() to the ThreadProc. stateInfo
becomes that object. I then assign that object to the type Form1 f1
(cast to Form1 so I know what kind of object (object stateInfo) is)
and then I get to work with my form.

It works, but am I correct here?

Apart from some terminology, that's basically right, yes.

Why are you doing it, out of interest?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote:

What I don't understand is how the thread part can run before the
Application.Run () can. How can it be executing code before it is
running?

The thread pool runs separately of the message queue. Application.Run
just starts a message pump for the given form, and waits until it
closes down.

Also, let me see if I am correct. The ThreadPool.Queu eUserWorkItem
sends the an instantiated new Form1() to the ThreadProc. stateInfo
becomes that object. I then assign that object to the type Form1 f1
(cast to Form1 so I know what kind of object (object stateInfo) is)
and then I get to work with my form.

It works, but am I correct here?

<snip>

I've just had another look at the code, and what you're doing it *not*
all right - you shouldn't be touching the form from any thread other
than the one which created it. You shouldn't be changing the icons etc
from a threadpool thread.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[jm]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in message news:<MP******* *************** **@msnews.micro soft.com>...

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote:

What I don't understand is how the thread part can run before the
Application.Run () can. How can it be executing code before it is
running?

The thread pool runs separately of the message queue. Application.Run
just starts a message pump for the given form, and waits until it
closes down.

Also, let me see if I am correct. The ThreadPool.Queu eUserWorkItem
sends the an instantiated new Form1() to the ThreadProc. stateInfo
becomes that object. I then assign that object to the type Form1 f1
(cast to Form1 so I know what kind of object (object stateInfo) is)
and then I get to work with my form.

It works, but am I correct here?

<snip>

I've just had another look at the code, and what you're doing it *not*
all right - you shouldn't be touching the form from any thread other
than the one which created it. You shouldn't be changing the icons etc
from a threadpool thread.

I thought I only created it in the Threadpool since I didn't do it in
Application.Run ().

[Jon Skeet [C# MVP]]

jm <jo************ *@yahoo.com> wrote:

I've just had another look at the code, and what you're doing it *not*
all right - you shouldn't be touching the form from any thread other
than the one which created it. You shouldn't be changing the icons etc
from a threadpool thread.

I thought I only created it in the Threadpool since I didn't do it in
Application.Run ().

No, you created it in the main thread, then passed it to the thread
pool thread.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[jm]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in message news:<MP******* *************** **@msnews.micro soft.com>...

jm <jo************ *@yahoo.com> wrote:

I've just had another look at the code, and what you're doing it *not*
all right - you shouldn't be touching the form from any thread other
than the one which created it. You shouldn't be changing the icons etc
from a threadpool thread.

I thought I only created it in the Threadpool since I didn't do it in
Application.Run ().

No, you created it in the main thread, then passed it to the thread
pool thread.

Could you point me to something I could read up on to learn more about
what I am doing wrong? I'm not sure what I should have done here.

Thanks.

[Jon Skeet [C# MVP]]

jm <jo************ *@yahoo.com> wrote:

No, you created it in the main thread, then passed it to the thread
pool thread.

Could you point me to something I could read up on to learn more about
what I am doing wrong? I'm not sure what I should have done here.

See http://www.pobox.com/~skeet/csharp/t...winforms.shtml for
general info about Windows Forms threading. I'm not entirely sure which
bit you're having problems with though - or why you're doing stuff on
the thread pool thread in the first place.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[j m]

I have a listening class that I modified from MSDN. I have Form1 with
the notifyIcon1 contextmenu, etc.

When the program loads I create Form1, but I do not run it. I only
wanted it to run as an icon in the system Tray. I also didn't want it
in Application.Run () because I needed to call my listening class from
the threadpool. I call from the threadpool because I want it to start
listening (with the while(true) in the listening class.) The Threapool
kicks off the new Form1() and the listener.

I put the new Form1() in Threadpool because I had to have some way to
instantiate Form1 *and* be able to reference it in my listening class.
Since the ThreadProc threadpool method is static, I could not send via
the "this" keyword, thus all my sending to the the Threadpool.

By sending it this way, I am still working (I thought, anyway) with the
original form at Main and can access the context menu at its events,
etc. (I have a context menu with events.)

Thanks again.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jon Skeet [C# MVP]]

j m <jo************ *@yahoo.com> wrote:

I have a listening class that I modified from MSDN. I have Form1 with
the notifyIcon1 contextmenu, etc.

When the program loads I create Form1, but I do not run it. I only
wanted it to run as an icon in the system Tray. I also didn't want it
in Application.Run () because I needed to call my listening class from
the threadpool. I call from the threadpool because I want it to start
listening (with the while(true) in the listening class.) The Threapool
kicks off the new Form1() and the listener.

I put the new Form1() in Threadpool because I had to have some way to
instantiate Form1 *and* be able to reference it in my listening class.
Since the ThreadProc threadpool method is static, I could not send via
the "this" keyword, thus all my sending to the the Threadpool.

By sending it this way, I am still working (I thought, anyway) with the
original form at Main and can access the context menu at its events,
etc. (I have a context menu with events.)

No - the problem is that you're changing things from the thread pool
thread, and you shouldn't be. Any time you need to change something in
the UI from a thread other than the one which created it, you need to
use Control.Invoke or Control.BeginIn voke.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[j m]

What would be the consequences of doing it like I am doing it or am I
just wrong?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!