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

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

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

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.public.dotnet.languages.csharp/<D0**********************************@microsoft.co m>

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.microsoft.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.microsoft.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.net> wrote in message
news:BF**********************************@microsof t.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.microsoft.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]

"Brian Keating EI9FXB" <csharp at briankeating.net> wrote in message
news:BF**********************************@microsof t.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.

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" wrote:

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.net> wrote in message
news:BF**********************************@microsof t.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.microsoft.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]

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

"Sami Vaaraniemi" wrote:

"Brian Keating EI9FXB" <csharp at briankeating.net> wrote in message
news:BF**********************************@microsof t.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.

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