By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,682 Members | 1,999 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,682 IT Pros & Developers. It's quick & easy.

When does a Windows Form create it's message processing thread

P: n/a
me
I have a Class Library that contains a Form and several helper classes. A
thread gets created that performs processing of data behind the scenes and
the Form never gets displayed (it is for debug puposes only and is not
normally visable to the user.) The Thread function is actually in the Form
class.

Now.. What I am seeing is that when I create an instance of this Class
Library's Form, which starts the worker thread, it seems to hose up the
displaying of the Form (it sees to be locked up) unless I place a
Application.DoEvents() call inside my worker threads function.

What this seems to tell me is that the thread I have created is blocking the
redrawing of the Form.. which doesnt make sense to me at all.

I have tried several ways to "resolve" this and here is what I have seen so
far:

1. DoEvents() in the Thread function seems to allow the Form to work
correctly.
2. Calling Show() and then Hide() of the Form before I start my worker
thread seems to allow me to then show and hide the Form later without any
problems.
3. If I do not show it and do not call DoEvents() then the Form does not
update when I perform a Show() later.

Any thoughts? I am almost thinking that the Form is not creating it's own
internal Message Handling thread until it is actually Show()'n and then when
it does it sees that I have a worker thread and attaches to it? Sounds
strange to me but that is what it looks like??

Any help would be appreciated.. You can email me at El******@hotmail.com
with any info you have.. I may not have access to this group later.....

Thx.

Jul 21 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Me,

When you have a from Form inherited form, than the form is showed directly
after (when you have that) the form load event. (When you don't make showing
in the contstructor or in that last event impossible of course).

I hope this helps?

Cor
Jul 21 '05 #2

P: n/a
Any thoughts? I am almost thinking that the Form is not creating it's own
internal Message Handling thread until it is actually Show()'n and then when
it does it sees that I have a worker thread and attaches to it? Sounds
strange to me but that is what it looks like??


There's no separate message handling thread. You need to call
Application.Run() on the thread you want to show UI to start the
message loop.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Jul 21 '05 #3

P: n/a
As Mattias said, there is no separate UI thread created. The current
thread becomes the message handling thread once you call
Application.Run(). That's why calling DoEvents() on the current thread
seems to work.

Regards
Senthil

Jul 21 '05 #4

P: n/a
me
Just a test.. My last post has not shown up yet.. hmm...
"me" <me@home.com> wrote in message
news:a-********************@comcast.com...
I have a Class Library that contains a Form and several helper classes. A
thread gets created that performs processing of data behind the scenes and
the Form never gets displayed (it is for debug puposes only and is not
normally visable to the user.) The Thread function is actually in the Form
class.

Now.. What I am seeing is that when I create an instance of this Class
Library's Form, which starts the worker thread, it seems to hose up the
displaying of the Form (it sees to be locked up) unless I place a
Application.DoEvents() call inside my worker threads function.

What this seems to tell me is that the thread I have created is blocking
the
redrawing of the Form.. which doesnt make sense to me at all.

I have tried several ways to "resolve" this and here is what I have seen
so
far:

1. DoEvents() in the Thread function seems to allow the Form to work
correctly.
2. Calling Show() and then Hide() of the Form before I start my worker
thread seems to allow me to then show and hide the Form later without any
problems.
3. If I do not show it and do not call DoEvents() then the Form does not
update when I perform a Show() later.

Any thoughts? I am almost thinking that the Form is not creating it's own
internal Message Handling thread until it is actually Show()'n and then
when
it does it sees that I have a worker thread and attaches to it? Sounds
strange to me but that is what it looks like??

Any help would be appreciated.. You can email me at El******@hotmail.com
with any info you have.. I may not have access to this group later.....

Thx.

Jul 21 '05 #5

P: n/a
me
I tried to upload a sample but it has not shown up yet.. If you want to take
a look at the sample here is a link to it and instructions on how to
duplicate what I am seeing.

Link:
https://home.comcast.net/~cbcox/MsgLoopTest.zip

Instructions:
"MsgLoopTest.sln" should open up a solution with 2 projects (MsgLoopTest and
SampleLibrary). When you run it you should get a form that has 4 buttons on
it.

Create Form (Creates an instance of TestForm2 from the SampleLibray)
Show Form (direct call to Show() method of Form)
Create Thread (Creates a thread that resides in the TestForm2 code)
Set Show Form Flag (Sets a flag in the TestForm2 code that causes the Thread
to call Show()).

Here are two different ways to "Show" TestForm2.

This seems to work fine.. The form is displayed and it updates with no
problems.
1. Click Create Form
2. Click Show Form

This way does not seem to work unless you put a call to
Application.DoEvents() inside the thread proc.
1. Click Create Form
2. Click Create Thread
3. Click Set Show Form Flag

This way does seem to work but requires you to show and then hide the form
first via the Show Form button.
1. Click Create Form
2. Click Create Thread
3. Click Show Form
4. Click Hide on the TestForm2
5. Click Set Show Form Flag

Now the question/problem is why does this work this way? It seems like
whatever Thread calls Show() first takes ownership of the message loop
instead of the thread that actually created the instance of the form.


"me" <me@home.com> wrote in message
news:a-********************@comcast.com...
I have a Class Library that contains a Form and several helper classes. A
thread gets created that performs processing of data behind the scenes and
the Form never gets displayed (it is for debug puposes only and is not
normally visable to the user.) The Thread function is actually in the Form
class.

Now.. What I am seeing is that when I create an instance of this Class
Library's Form, which starts the worker thread, it seems to hose up the
displaying of the Form (it sees to be locked up) unless I place a
Application.DoEvents() call inside my worker threads function.

What this seems to tell me is that the thread I have created is blocking
the
redrawing of the Form.. which doesnt make sense to me at all.

I have tried several ways to "resolve" this and here is what I have seen
so
far:

1. DoEvents() in the Thread function seems to allow the Form to work
correctly.
2. Calling Show() and then Hide() of the Form before I start my worker
thread seems to allow me to then show and hide the Form later without any
problems.
3. If I do not show it and do not call DoEvents() then the Form does not
update when I perform a Show() later.

Any thoughts? I am almost thinking that the Form is not creating it's own
internal Message Handling thread until it is actually Show()'n and then
when
it does it sees that I have a worker thread and attaches to it? Sounds
strange to me but that is what it looks like??

Any help would be appreciated.. You can email me at El******@hotmail.com
with any info you have.. I may not have access to this group later.....

Thx.

Jul 21 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.