Windows Form in seperate thread

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello all,
Wonder what approach is used for this problem.

I have a MDIApplication, the MDIClinets are to be in a seperate thread.
So I've done something like this,

// Create a new Show method that starts a new thread
public new void Show()
{
Thread t = new Thread(new ThreadStart(ThreadProc));
t.Start();
}


public void ThreadProc()
{
base.Show();
}

Now my problem is that I basically don't have a run loop, so as soon as the
Form shows the thread exits and I'm pretty much left in the soup.

I'm sure other people have done this in .NET?
Any ideas suggestions etc?

Thanks for you time
Brian Keating.
 
Hello all,
Wonder what approach is used for this problem.

I have a MDIApplication, the MDIClinets are to be in a seperate thread.
So I've done something like this,

// Create a new Show method that starts a new thread
public new void Show()
{
Thread t = new Thread(new ThreadStart(ThreadProc));
t.Start();
}


public void ThreadProc()
{
base.Show();
}

Now my problem is that I basically don't have a run loop, so as soon as the
Form shows the thread exits and I'm pretty much left in the soup.

I'm sure other people have done this in .NET?
Any ideas suggestions etc?

Thanks for you time
Brian Keating.
Click to expand...

Call Application.Run in the new thread...

private void ThreadProc ()
{
Application.Run (new Form ());
}
 
Hi Tom

How does this work with the "Thou Shalt have one User Interface thread per
application" rule - do we get a separate message pump for each MDI Child
window with this approach?

Just interested really...

Nigel Armstrong
 
The precise rule states

"Thou shalt not access a UI element from a thread other than the thread that created it"

Internet Explorer has multiple UI threads for example - each IE windows runs in its own UI thread even though there is noly one process.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi Tom

How does this work with the "Thou Shalt have one User Interface thread per
application" rule - do we get a separate message pump for each MDI Child
window with this approach?

Just interested really...
 
Yes i'm pretty interested in same,
Also wondering how cleanup occurs? Application.ExitThread(); ?

I fear the biggest problem is going to be setting the MDIParent, I don't
know if this is going to work in a seperate thread.

I've been down this road before with a multithreaded C++/WTL application and
it was a heartache to implement, I think c# is going to be alot harder to do
this but the next few days will tell.

thanks for your help.
 
Hi Richard

Thanks for this - very helpful to me! In the specific case of an MDI
application, what happens with Menu merging? We have the MDI parent form on
one thread, and the child forms created on distinct threads...

Nigel Armstrong
 
Woooahh!

you can create top level windows in separate threads not MDI children. The parent and children would be attempting to talk to eachother from separate threads which breaks the golden rule

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk


nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<[email protected]>

Hi Richard

Thanks for this - very helpful to me! In the specific case of an MDI
application, what happens with Menu merging? We have the MDI parent form on
one thread, and the child forms created on distinct threads...

Nigel Armstrong
 
Hi Tom

How does this work with the "Thou Shalt have one User Interface thread per
application" rule - do we get a separate message pump for each MDI Child
window with this approach?

Just interested really...

Nigel Armstrong
Click to expand...

Ooops! I missed the MDI part. No can do. This would cause definate
issues. I think you'll need to change your design...

As for top level windows, yes, you get a message pump per thread.
 
Ok guys, thanks for your help,
I wonder if anyone has a suggestion on another approach.

Let me explain my problem, I've services running on my system, my
application receives diagnostic messages from these services, what i want to
do is create an MDIChild window for each service that sends a message.

Ok so far so good, but I get problems if one service is constantly sending
messages to it's window because, this window is very busy updating it's view,
hence because it's in the same thread at all other MDIChild windows and the
MDIParent window the whole application is un responsive becasue this window
is too busy.


I did manage to get the Multithread MDI working and stable in a C++ ATL/WTL
application but it proved a heartache to say the least. I'd rather not go
down that road again.

Suggestions welcome.
Thanks in advance
Brian.
 
If you use MDI you have limit of one thread, which is UI distributing
messages between child windows. I would go away from this paradigm.

You might be better off if you create forms on threads and use
Application.Run for these forms. This seems to create separate message pumps
and keeps windows pretty responsive if painting code is Ok. The only
drawback I've seen so far is that you have to manage separate threads /
forms as one applications - it adds some unnecessary complexity,

I am not sure why you want to have MDIChild for each service in one
application. Service is separate process, so related standalone form seems
to be natural companion.

HTH
Alex

Brian Keating EI9FXB said:
Ok guys, thanks for your help,
I wonder if anyone has a suggestion on another approach.

Let me explain my problem, I've services running on my system, my
application receives diagnostic messages from these services, what i want to
do is create an MDIChild window for each service that sends a message.

Ok so far so good, but I get problems if one service is constantly sending
messages to it's window because, this window is very busy updating it's view,
hence because it's in the same thread at all other MDIChild windows and the
MDIParent window the whole application is un responsive becasue this window
is too busy.


I did manage to get the Multithread MDI working and stable in a C++ ATL/WTL
application but it proved a heartache to say the least. I'd rather not go
down that road again.

Suggestions welcome.
Thanks in advance
Brian.

Click to expand...
 
Brian Keating EI9FXB said:
Ok guys, thanks for your help,
I wonder if anyone has a suggestion on another approach.

Let me explain my problem, I've services running on my system, my
application receives diagnostic messages from these services, what i want
to
do is create an MDIChild window for each service that sends a message.

Ok so far so good, but I get problems if one service is constantly
sending
messages to it's window because, this window is very busy updating it's
view,
hence because it's in the same thread at all other MDIChild windows and
the
MDIParent window the whole application is un responsive becasue this
window
is too busy.


I did manage to get the Multithread MDI working and stable in a C++
ATL/WTL
application but it proved a heartache to say the least. I'd rather not go
down that road again.
Click to expand...

You should be able to handle this situation gracefully if you decouple the
window's UI operations (i.e., repaint) completely from the processing of
diagnostics messages. In other words, have the diagnostics message receiver
thread place the information into your own queue (or list, doesn't matter),
and then call Invalidate for the window (via Control.Invoke or BeginInvoke
to make it thread-safe).

If you really get lots of diagnostics messages and calling Invalidate is
still not good enough, then consider not calling Invalidate every time a
diagnostics message arrives. Simply place the diagnostics information into
your own queue and have the UI thread check the state of the queue e.g.,
once per second on a timer. This way you will get a refresh at a comfortably
slow rate no matter how fast the diagnostics messages arrive.

I'd go creating forms in multiple threads only as the very last resort.

Regards,
Sami
 
Hi Alex,
I've a test app created that used the Application.Run as you suggest,
this is pretty close to what I want, however i do get some events twice etc,

but I hope i'm getting close.
thanks for your help.
regards
Brian.

AlexS said:
If you use MDI you have limit of one thread, which is UI distributing
messages between child windows. I would go away from this paradigm.

You might be better off if you create forms on threads and use
Application.Run for these forms. This seems to create separate message pumps
and keeps windows pretty responsive if painting code is Ok. The only
drawback I've seen so far is that you have to manage separate threads /
forms as one applications - it adds some unnecessary complexity,

I am not sure why you want to have MDIChild for each service in one
application. Service is separate process, so related standalone form seems
to be natural companion.

HTH
Alex

Brian Keating EI9FXB said:
Ok guys, thanks for your help,
I wonder if anyone has a suggestion on another approach.

Let me explain my problem, I've services running on my system, my
application receives diagnostic messages from these services, what i want to
do is create an MDIChild window for each service that sends a message.

Ok so far so good, but I get problems if one service is constantly sending
messages to it's window because, this window is very busy updating it's view,
hence because it's in the same thread at all other MDIChild windows and the
MDIParent window the whole application is un responsive becasue this window
is too busy.


I did manage to get the Multithread MDI working and stable in a C++ ATL/WTL
application but it proved a heartache to say the least. I'd rather not go
down that road again.

Suggestions welcome.
Thanks in advance
Brian.
Click to expand...
Click to expand...
 
Hi Sami,
Tnx for your help, I'm still doing up a few tests so when I finally get a
"workable" solution I'll post an article on it.

thanks for your time.

Brian
 
Back
Top