How to start a form on a new thread?

[Randolph Neall]

I'm having trouble instantiating and SHOWing a form on a new thread. The
form appears briefly then disappears from the screen and the taskbar. Is
there a sample somewhere how to do this? Preferrably C#?

Show(), for its part, as I understand it, despite its modelessness, does not
start a new thread, and therefore if the form runs a process that takes
time, the rest of the app would freeze, or so it would seem. Hence, the need
for a form on a new thread.

Thanks,

Randy Neall

 

[Guest]

that's correct - creating new window does not generate new UI process - it's just that your mouse and other inputs get sent to the window that has input, and it's managed by the same main UI thread. If you need to be doing something else in the background you can create a worker thread (as multiple UI threads get tricky and not recommended unless you really need them - like maybe in game development).

 

[Randolph Neall]

Sean,

Thanks much. Tell me: any time I use new Thread and ThreadStart, etc., am I
using what could be termed a "worker thread." There is the ThreadPool class
and the Thread class. Are "worker threads" confined to ThreadPool?

You've really been a help. On the basis of what you said I will abandon all
attempts to start a form on a new thread, just the process that the form
would run.

Randy

that's correct - creating new window does not generate new UI process -

it's just that your mouse and other inputs get sent to the window that has
input, and it's managed by the same main UI thread. If you need to be doing
something else in the background you can create a worker thread (as multiple
UI threads get tricky and not recommended unless you really need them - like
maybe in game development).

 

[Randolph Neall]

Thanks!

Randy

ThreadPool manages a pool of threads for you, this would be useful in

situations when many short-lived threads are created and destroyed.
ThreadPool internally reuses threads that otherwise would be too expensive
to keep creating over and over.

 

[Klaus Löffelmann]

Randolph,

in addition to Sean:
Keep in mind that opinions are differing wether to use the threadpool in
windows application or not. Fact is: The threadpool runs in the multi
threaded apartment, windows applications do not. So you could run into
problems if you use the threadpool AND COM-Components (a FileOpenDialog e.g.
already is one, so you run quicker into the use of COM components than you
might assume!) in your application.

For using a second UI-Thread: It's easier than most people think:

1. Create a new thread that will become the 2. UI-Thread
2. In that thread add the Application.ThreadExit-Event via AddHandler to a
Event Handler Procedure
3. Create a new Form instance (InstanceOfThatForm) that is to be bound to
the new UI-Thread
4. Start the 2. UI-Thread with Application.Run(InstanceOfThatForm)

Then: If you receive the Application.ThreadExit-Event, in the event handler
do

InstanceOfThatForm.Close
Application.ExitThread

If the user closes the form (InstanceOfThatForm), nothing additional has to
be done, since the thread closes propertly itself.

Hope that helps,

Klaus

 

[Randolph Neall]

Hello Klaus,

Thank you for jumping in! I will keep this post for future reference.

It does look like when one attempts to start a form on a new thread that one
is definitely departing from the beaten track. I was unaware of this. I had
used something called Clarion before, where this was common, and simply
thought this must be the way to do it with C# and .Net as well.

Now that I've learned from Sean, the question I'd ask now would be why one
would want to go through the process of developing more than one UI thread?
Do you ever do what you outline below? Under what circumstances?

Also, could you give a bit more detail about how to do step 2, below?

Again, thank you very much!

Randy Neall

 

[Klaus Löffelmann]

Randloph,

first of all, you can show a form and start a new thread there. If the
worker thread has been started by the new form, it doesn't freeze. But
that's not creating a new UI-Thread, as I pointed out.

A good example for a new UI-Thread could be something like the output window
of the VS-Environment. If you want to implement such a thing in your
application (as a status window, e.g.), you might want to have a second
UI-Thread. One advantage is that you don't need to take care of using Invoke
of a control to change its property thread-safely.
Another thing is, that you could for example create a new WriteLine-Method
that "outputs" text into a form running in a 2. UI-Thread without ever
taking care of synchronisation issues of the "other side" (that is, all the
other threads, that might be running and using this function). The
synchronisation of the output would be totally done in the form that runs on
the second UI-Thread, and that brings comfort and more overview with the
actual programming, because it's totaly excapsulated. Since it's running in
a different thread, it can never freeze in addition (when the main UI-Thread
blocks itself due to an extensive operation).

Think of the following scenario. The first time you use

MyThreadSafeOutput.WriteLine("xxxxx")

from any running thread, a windows opens and prints the text. No connection
to your first UI-Thread is needed, no instancing has to be done. If your
main application closes, the output windows closes, too. For that you would
need a second ui-thread. I developed such a thing for a book I currently
write for Microsoft Press Germany. Since I have to meet a deadline, I have
no time at the moment to translate the comments; but if you still
interested, I'll translate it for you sometime next month. Just send me a
reminder at (e-mail address removed) (spell the last name with OE not Ö!).

Klaus

 

[Randolph Neall]

Klaus,

I've often wondered how to do just such a thing, and what a WriteLine
object on a second UI thread would look like.

I'm grateful for your contribution to this thread. And yes, when you get
time, I'd like to see your translation. I took German in college but that
was a long time ago. Actually, I think I could at least understand the code
even without translation.

Thanks again,

Randy Neall