Multi-Form app using threading...

  • Thread starter Thread starter Doogman
  • Start date Start date
D

Doogman

If I close a child form that is running on its own thread using
Application.Run as the startup, will it also kill the thread that it runs
in? Or do I need to kill the thread from the base class? Or from the
threaded form with a callback to the base.class from the child form by
overiding the On_Closing event?

thanks all,
doogman
 
Hi Doogman,

Closing the Form will cause Application.Run to exit. If you don't have any
code that loops afterwards the code that the thread executes will end and
the tread will be "killed". You don't have to do anything else. Beside,
killing the thread from outside is not good practice and should be avoided.

B\rgds
100
 
Doogman,

All of the forms run in the same thread. I think that you meant to ask
if the thread that the form spawned will be killed. In this case, no, it
will not. You should check the Closing event of the form to see if the
thread is still alive. If it is, you can call Abort. You can place this
code in a base class if you don't want to replicate it across all of your
forms.

Hope this helps.
 
This is actually very, very incorrect. For any process, you are only
supposed to have one UI thread. Doing otherwise will have unpredictable
results. This has been the model for Windows programming for as long as it
has been around.

Because of this, per process, there should only be one call to the
static Run method on the Application class.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

100 said:
Hi Nicholas,
You can start a new thread, create a form on it and call
Application.Run(form).
This will run a message loop for this very thread and will make it UI. You
can have as many UI threads as you want.

B\rgds
100

in message news:[email protected]...
Doogman,

All of the forms run in the same thread. I think that you meant to ask
if the thread that the form spawned will be killed. In this case, no, it
will not. You should check the Closing event of the form to see if the
thread is still alive. If it is, you can call Abort. You can place this
code in a base class if you don't want to replicate it across all of your
forms.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Doogman said:
If I close a child form that is running on its own thread using
Application.Run as the startup, will it also kill the thread that it runs
in? Or do I need to kill the thread from the base class? Or from the
threaded form with a callback to the base.class from the child form by
overiding the On_Closing event?

thanks all,
doogman
 
Hi Nicholas,
You can start a new thread, create a form on it and call
Application.Run(form).
This will run a message loop for this very thread and will make it UI. You
can have as many UI threads as you want.

B\rgds
100

Nicholas Paldino said:
Doogman,

All of the forms run in the same thread. I think that you meant to ask
if the thread that the form spawned will be killed. In this case, no, it
will not. You should check the Closing event of the form to see if the
thread is still alive. If it is, you can call Abort. You can place this
code in a base class if you don't want to replicate it across all of your
forms.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Doogman said:
If I close a child form that is running on its own thread using
Application.Run as the startup, will it also kill the thread that it runs
in? Or do I need to kill the thread from the base class? Or from the
threaded form with a callback to the base.class from the child form by
overiding the On_Closing event?

thanks all,
doogman
 
100 said:
Hi Nicholas,
You can start a new thread, create a form on it and call
Application.Run(form).
This will run a message loop for this very thread and will make it UI.
You can have as many UI threads as you want.

B\rgds
100

Nicholas Paldino said:
Doogman,

All of the forms run in the same thread. I think that you meant
to ask
if the thread that the form spawned will be killed. In this case,
no, it will not. You should check the Closing event of the form to
see if the thread is still alive. If it is, you can call Abort. You
can place this code in a base class if you don't want to replicate it
across all of your forms.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Doogman said:
If I close a child form that is running on its own thread using
Application.Run as the startup, will it also kill the thread that
it runs
in? Or do I need to kill the thread from the base class? Or from
the threaded form with a callback to the base.class from the child
form by overiding the On_Closing event?

thanks all,
doogman

Perfect...thanks! Between the three messages above I confirmed how I
thought it was supposed to be. Hey, its Friday and my brain is throwing
null exception's!! haha! Thanks again peoples...

doogman
 
This is actually very, very incorrect. For any process, you are
only
supposed to have one UI thread. Doing otherwise will have
unpredictable results. This has been the model for Windows
programming for as long as it has been around.

Because of this, per process, there should only be one call to the
static Run method on the Application class.

Yeah, I understood that. Indeed that is the Holy Grail of windows
programming. I am basically just calling a seperate class, form, and data
from a base form. I want to have, say, vendor maintenance, and customer
maintenance open at the same time, on seperate threads, or should I just
Application.run each one and let windows handle the threading? No I am
confused again....my mind is stuck in debug and looking for release.

doogman
 
Doogman,

Only call Application.Run ONCE for the process, that is when the first
form (or MDI parent form) is called. If you call Applciation.Run again, you
are running a loop within a loop and have put the outside loop on hold until
the processing is complete. You are also creating one hell of a stack every
time you do this.

You can do your processing on another thread, but all of the forms, just
run them on the main thread. When I say processing, you do all of the
number crunching, downloading, etc, etc on other threads. When you need to
update the UI though, you do it through calls to the Invoke method on any of
the forms open or controls on the forms, as it will marshal the call to the
UI thread.
 
Doogman,

Only call Application.Run ONCE for the process, that is when the
first
form (or MDI parent form) is called. If you call Applciation.Run
again, you are running a loop within a loop and have put the outside
loop on hold until the processing is complete. You are also creating
one hell of a stack every time you do this.

You can do your processing on another thread, but all of the
forms, just
run them on the main thread. When I say processing, you do all of the
number crunching, downloading, etc, etc on other threads. When you
need to update the UI though, you do it through calls to the Invoke
method on any of the forms open or controls on the forms, as it will
marshal the call to the UI thread.

Roger that! I see what you mean and what is meant by one thread for UI.
Basically if I perform math, etc for the UI call that math class in its
own thread and update my UI using an interface to the math/crunching, or
whatever the cpu intensive class does. Simple textBox entry and reading
really does not need any threading then....

Thanks again...
doogman
 
Doogman,
If I close a child form that is running on its own thread using
Application.Run as the startup, will it also kill the thread that it runs
in?

If thread A creates thread B, the termination of B will not cause A to
terminate. Note that if you set B.IsBackground = True and terminate A, then B
will be terminated also. If not then your application may not close down as you
had hoped.
 
Doogman,

If you are going to update the text in the textbox, then you have to
make sure that the code that sets the text of the textbox is run on the UI
thread.
 
Nicholas,
This is actually very, very incorrect. For any process, you are only
supposed to have one UI thread. Doing otherwise will have unpredictable
results.

Are you sure of what you are asserting here. I hear (read) this for my first
time.
Message queues (MQ) are per thread. UI thred is thread that has MQ attached.
When you start a thread in winfows it doesn't have MQ and one is created
when the thread calls for its first time any of the functions for retrieving
a message. You can find several examples of *how to create an UI thread* in
MSDN.
This has been the model for Windows programming for as long as it
has been around.

Ok. Take a look at Windows Explorer or Internet Explorer. If you open 2
explorers you will have only *one process* and two UI threads (any of the
explorers runs in its own thread).
I believe at least Windows Exlporer stays around since Win95 and the threads
were introduced. I'm not sure if Win32s had threads, though.
Because of this, per process, there should only be one call to the
static Run method on the Application class.


As a matter of fact .NET has the concept of *Application Domains*. Where
more then one assemblies (with their own main functions and UI threads) can
run in the same windows process. Isn't it just one windows process with many
UI threads?

Of course having more then one UI thread is not usual, but is completely
correct.

B\rgds
100
--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

100 said:
Hi Nicholas,
You can start a new thread, create a form on it and call
Application.Run(form).
This will run a message loop for this very thread and will make it UI. You
can have as many UI threads as you want.

B\rgds
100

in message news:[email protected]...
Doogman,

All of the forms run in the same thread. I think that you meant
to
ask
if the thread that the form spawned will be killed. In this case, no, it
will not. You should check the Closing event of the form to see if the
thread is still alive. If it is, you can call Abort. You can place this
code in a base class if you don't want to replicate it across all of your
forms.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

If I close a child form that is running on its own thread using
Application.Run as the startup, will it also kill the thread that it runs
in? Or do I need to kill the thread from the base class? Or from the
threaded form with a callback to the base.class from the child form by
overiding the On_Closing event?

thanks all,
doogman
 
Nothing in Windows prevents you from creating another form on another thread
and run it independently from main UI form on separate thread.
However, as Nicholas rightly remarks, not with Application.Run method. Use
Form.Show instead.

HTH
Alex

Nicholas Paldino said:
Doogman,

Only call Application.Run ONCE for the process, that is when the first
form (or MDI parent form) is called. If you call Applciation.Run again, you
are running a loop within a loop and have put the outside loop on hold until
the processing is complete. You are also creating one hell of a stack every
time you do this.

You can do your processing on another thread, but all of the forms, just
run them on the main thread. When I say processing, you do all of the
number crunching, downloading, etc, etc on other threads. When you need to
update the UI though, you do it through calls to the Invoke method on any of
the forms open or controls on the forms, as it will marshal the call to the
UI thread.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Doogman said:
Yeah, I understood that. Indeed that is the Holy Grail of windows
programming. I am basically just calling a seperate class, form, and data
from a base form. I want to have, say, vendor maintenance, and customer
maintenance open at the same time, on seperate threads, or should I just
Application.run each one and let windows handle the threading? No I am
confused again....my mind is stuck in debug and looking for release.

doogman
 
Hi AlexS,

AlexS said:
Nothing in Windows prevents you from creating another form on another thread
and run it independently from main UI form on separate thread.
However, as Nicholas rightly remarks, not with Application.Run method. Use
Form.Show instead.
Calling Form.Show without Application.Run will cause the form to show and
stay frozen because there is no windows message loop running on the new
thread. It won't do.
To create a form in a new thread you have to use Application.Run in order to
make the thread UI.
The following is the quote form MSDN baout the Application.Run method:

"Begins running a standard application message loop on the current thread."

It starts a message loop on the current thread so there won't be any
interferences with the message loops in other threads.

B\rgds
100
HTH
Alex

in message news:[email protected]...
Doogman,

Only call Application.Run ONCE for the process, that is when the first
form (or MDI parent form) is called. If you call Applciation.Run again, you
are running a loop within a loop and have put the outside loop on hold until
the processing is complete. You are also creating one hell of a stack every
time you do this.

You can do your processing on another thread, but all of the forms, just
run them on the main thread. When I say processing, you do all of the
number crunching, downloading, etc, etc on other threads. When you need to
update the UI though, you do it through calls to the Invoke method on
any
of
the forms open or controls on the forms, as it will marshal the call to the
UI thread.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Doogman said:
"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in
This is actually very, very incorrect. For any process, you are
only
supposed to have one UI thread. Doing otherwise will have
unpredictable results. This has been the model for Windows
programming for as long as it has been around.

Because of this, per process, there should only be one call to the
static Run method on the Application class.


Yeah, I understood that. Indeed that is the Holy Grail of windows
programming. I am basically just calling a seperate class, form, and data
from a base form. I want to have, say, vendor maintenance, and customer
maintenance open at the same time, on seperate threads, or should I just
Application.run each one and let windows handle the threading? No I am
confused again....my mind is stuck in debug and looking for release.

doogman
 
Back
Top