Windows Form in seperate thread

On 2004-11-25, Brian Keating EI9FXB <> wrote:

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(Thr eadProc));
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.

Call Application.Run in the new thread...

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

--
Tom Shelton [MVP]

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

"Tom Shelton" wrote:

On 2004-11-25, Brian Keating EI9FXB <> wrote:

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(Thr eadProc));
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.

Call Application.Run in the new thread...

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

--
Tom Shelton [MVP]

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.Exi tThread(); ?

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.
"Nigel Armstrong" wrote:

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

"Tom Shelton" wrote:

On 2004-11-25, Brian Keating EI9FXB <> wrote:

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(Thr eadProc));
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.

Call Application.Run in the new thread...

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

--
Tom Shelton [MVP]

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

"Richard Blewett [DevelopMentor]" wrote:

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...

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.publi c.dotnet.langua ges.csharp/<D0************ *************** *******@microso ft.com>

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

"Richard Blewett [DevelopMentor]" wrote:

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.

On 2004-11-25, Nigel Armstrong <Ni************ @discussions.mi crosoft.com> wrote:

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

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.

--
Tom Shelton [MVP]

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.

"Tom Shelton" wrote:

On 2004-11-25, Nigel Armstrong <Ni************ @discussions.mi crosoft.com> wrote:

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

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.

--
Tom Shelton [MVP]

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" <csharp at briankeating.ne t> wrote in message
news:BF******** *************** ***********@mic rosoft.com...

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.

"Tom Shelton" wrote:

On 2004-11-25, Nigel Armstrong <Ni************ @discussions.mi crosoft.com> wrote:

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

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.

--
Tom Shelton [MVP]