Fully functional form in a seperate thread

  • Thread starter Thread starter Matthias Steinbart
  • Start date Start date
M

Matthias Steinbart

Hi,

I'm looking for the easiest way to display a fully functional form in a
different thread. I've created a test app and it doesn't seem to work as
expected. From my MainForm, a button is clicked and the eventhandler starts
a new thread. The thread-function looks like this.

protected static void run() {
// create a new window
wndStateMachineMonitor wndMonitor = new wndStateMachineMonitor();
wndMonitor.Show();
wndMonitor.Invalidate();


while(getStopRequest() == false) {
// every now and then we'll check for some data an, if necessare update
the wndMonitor
// DoSomething(...);
Thread.Sleep(updateInterval);
wndMonitor.Invalidate();
}

// close down the window
wndMonitor.Close();

}

I think that all varialbles are pretty selfexplanatory. What am I missing
out?
 
Matthias,

when form is on separate thread it cannot use reliably main thread message
pump. If you want to make it alive you have to start separate message pump
with Application.Run - before and in addition to Show.

HTH
Alex
 
Hi Matthias,

Message loops (pumps) are per thread. So if you want yor form created and
alive in a worker thread you have two choices
1. To show the form as a modal dialog (Form.ShowDialog)
2. Start a message loop in the worker thread
wndStateMachineMonitor wndMonitor = new wndStateMachineMonitor();
Application.Run(wndMonitor);

Bare in mind that any code after Run method will be executed only when
wndMonitor is closed. So, I guess you need to change your thread logic.
 
Hi Alex,

thanks for your help. Though I don't actually understand, why the message
pump won't work properly if in a seperate thread, it works when I use
Application.Run(...), thus my problem is solved.

Matthias
 
This is a limitation inherited from prior .NET (native Win32).

A message is not send to a window, but to a thread, so you might remember
the:
while(GetMessage(...))
DispatchMessage(...);

Loop in Win32, this is what Application.Run does.

So a message is delivered to a thread and the thread gets it with
GetMessage. The next call is DispatchMessage which looks out the registered
handler (callback function) that needs to handle the message (for you form
in this case).

So when you create a window and register is hwnd, it is attached to a
thread, which must process the messages.

Hopefully this clears it up a bit...

- Joris
 
You've clearly got no idea of the principles of threading if you're intending
to create a separate thread just to host a form in.
You should have one main thread in an application that controls all the UI.
After all, there is only one mouse and one keyboard plugged into the
computer. If you're unable to keep this UI responsive enough through the use
of worker threads for long operations, then you're certainly not good enough
a programmer to be firing off UI threads willy-nilly all over the place.
Or is it just that you don't understand the principle of how to transfer
control back to the main thread when you want to update the UI, so you
instead put the whole UI in the worker thread?

(Somebody else...please tell him! ...back me up here guys - don 't just
tell him a hack!)
 
He clearly doesn't understand the difference between a UI thread and a worker
thread and why a thread method doesn't exit as soon as it's shown a form....
 
Hi Patty,
You've clearly got no idea of the principles of threading if you're intending
to create a separate thread just to host a form in.
You should have one main thread in an application that controls all the
Click to expand...
UI.

Windows long ago became multithread operation system. You can have as many
UI threads as you want. Look at Windows Explorer. There is only one process
and different threads for each UI you've started.
What we've suggested is not a hack. It is the way Windows works. We are
talknig .NET here, right? What are all those application domains that run in
one process. Aren't they just one process with many UI threads from Windows
OS point of view?
If Matthias needs more than one UI thread I believe he has good reason for
that.
After all, there is only one mouse and one keyboard plugged into the
computer.
Click to expand...

Are you telling us that you keep only one program running at a time?
If you're unable to keep this UI responsive enough through the use
of worker threads for long operations, then you're certainly not good enough
a programmer to be firing off UI threads willy-nilly all over the place.
Or is it just that you don't understand the principle of how to transfer
control back to the main thread when you want to update the UI, so you
instead put the whole UI in the worker thread?
Click to expand...

Yes, I know programming in one thread (keeping UI in only one thread) is
easier, but pls respect other programmers' needs.

After all how do you know what is he able or unable?
In sake of good manners you should refrain of giving qualification such as
"then you're certainly not good enough a programmer..."

(Somebody else...please tell him! ...back me up here guys - don 't just
tell him a hack!)
Click to expand...

How can anyone back you up here?!
 
Patty O'Dors said:
He clearly doesn't understand the difference between a UI thread and a worker
thread and why a thread method doesn't exit as soon as it's shown a
Click to expand...
form....

Please enlighten me...
 
Back
Top