Move a Thread to Main Thread using VB.Net

Question

0.00/5 (No votes)

See more:

I have a thread which has a function to Generate and Show a new Form. The thread do an invinite loop using while true. Because of that, my form always show up only white form. I must stop the invinite loop to make the form work.

The problem is, i don't want to stop the invinite loop. Can i ask the form that created in my thread to move to the other thread??

Thanks for the help.. :)

Posted 12-Jul-10 23:58pm

Dwi Prawira

Add a Solution

3 solutions

Solution 3

Your form should be created on the UI thread, not your background thread. I'd marshal a call to a method that creates the form back to the UI thread. This will keep your infinite loop going as well as eliminate the need for Sleep and DoEvents.

Posted 15-Jul-10 5:24am

Dave Kreskowiak

Comments

Jimmanuel 15-Jul-10 13:55pm

Reason for my vote of 5
Good answer.

Dwi Prawira 15-Jul-10 20:11pm

i think my form must generate by thread.. because, my application is messenger. the client have a thread that always listen to server.. whenever server send a request to the client, the client should show the form.. Application.DoEvents works great on my application.

Dave Kreskowiak 15-Jul-10 22:04pm

Wrong. Your form does NOT have to be generated by a thread. Your CONTENT for the form can come from a thread. You then just invoke a method on the UI thread to update the form with the new content.

Creating and using forms and controls introduces bugs in your code that are nearly impossible to replicate and find because of bad cross-thread operations. The general rule of thumb is if the user can see the control, it has to be created and updated on the UI (startup) thread. If you want to have problems that are a @#*%# to find and fix, keep doing it your way. It MAY work for you on your machine just fine, but out in the wild, on any number of users PC, I guarantee that your existing method is not going to hold up.

Solution 2

Wow... Thats work great.. thanksss...

Posted 13-Jul-10 16:03pm

Dwi Prawira

Comments

Johnny J. 14-Jul-10 3:20am

Sure it works. If you want to know WHY it works, check out my reply to this guy who had a similar problem:

http://www.codeproject.com/Answers/90284/Using-BackgroundWorker.aspx?cmt=4098#answer1

Dwi Prawira 14-Jul-10 5:22am

OK... Thanks for your advise.. :)

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Johnny J. · Accepted Answer · 2010-07-13T00:17:00

Solution 1

Insert an Application.DoEvents or a Thread.Sleep(...) in your infinite loop

Posted 13-Jul-10 0:17am

Johnny J.

Updated 13-Jul-10 0:18am

v2

Comments

Nish Nishant 13-Jul-10 23:00pm

Reason for my vote of 5
Worth a 5.

Dave Kreskowiak 15-Jul-10 11:23am

Reason for my vote of 1
Forms should not be created by the background thread at all and this is no solution to the problem.

Jimmanuel 15-Jul-10 13:53pm

Reason for my vote of 1
Calling Application.DoEvents in this case is a misuse of that method.

Johnny J. 15-Jul-10 14:20pm

Bullshit Jimmanuel - That's a statement that needs proving. Too bad I can't downvote a comment...

Jimmanuel 15-Jul-10 16:13pm

Well then, how about telling us how you really feel :)

Dave's answer is IMO the correct one. Modeless forms should not be shown from background threads. Period. Whenever you attempt it you're forced to call Application.DoEvents because otherwise the form would never get a chance to process window messages and it'll appear frozen, as the OP has found out. Why I consider this a misuse is because background threads are for doing background work, not running windows message pumps. To show a form the form should have it's own thread exclusively for processing messages but since in this case the primary purpose of the thread is to do some background work, calling Application.DoEvents is improper.

Showing a modeless form from a background thread and then sleeping does nothing because if the thread is asleep then it obviously can't process the window messages and the form will stay as frozen as it was before (and i just tested this to confirm).

Johnny J. 16-Jul-10 4:20am

OK, sure - I'm not sure this is the correct place for an ethical discussion, but here goes: Dave is 50% right in his first statement, and you're dead wrong in your first statement. For this reason:

I completely agreee with Dave (and you in your latter comment) that forms should never be opened from a background thread. That is the 50% he's right in. But the fact is that that is precisely what the OP has done and because of that he has a problem. What should we do about that? Try to solve his problem or merely tell him that what he has done is wrong and that he should redesign his whole application?

When Dave says "this is no solution to the problem", he's definitely wrong. My answer did solve the OP's problem, so it was indeed a solution. Then we can all agree that the application is not designed in the best way, but it does work. Dave should have downvoted the question instead of the answer - that would have made more sense.

So I simply offered a solution to get the app working from where it was instead of having to redesign everything.

Now, getting to your statement: OK, so the OP opens a form from his background thread and shouldn't do that, but if you overlook that and think about this: No matter WHAT "background work" (as you put it) you do, having a loop in it will freeze all other threads for the execution time of the loop if you don't call either DoEvents or Sleep (historically, these two used to be identical, but for some reason they are not 100% identical anymore, and I have found that in a few cases, DoEvents works better than Sleep). That is what the method is there for. Read the MSDN documentation. So saying that it is a misuse of the method is wrong. It's using the method for precisely what it's created for: Allowing other events to run. The fact that there is an open form involved is of little or no consequence because it could just as well have been some other code that locked the threads (and that is by the way what it is here too - it's not the form(s) that lock the other threads, but the infinite loop).

On a side note: If you check out the link I gave the OP to another similar answer, you will see that I normally also advise against having infinite loops in background threads because of this very thing. But since the OP is dead set on it, the only solution is indeed to use DoEvents or Sleep.

Both your and Daves comments and votes are in fact out of place because they're directed at the OP's application design, which basically has nothing to do with neither the question nor the answer.

Jimmanuel 16-Jul-10 10:05am

Agree - this would be better in the forums but since it's already here . . .

"Try to solve his problem or merely tell him that what he has done is wrong and that he should redesign his whole application?"

There's no way to know if this involve redesigning the entire application or just one small part. What I do know is that when you have a problem it's ALWAYS better to treat the cause instead of it treating the symptoms. Fixing the cause is a one time thing. If you don't then symptoms will keep popping up later on down the road. And it's not just THIS problem we're talking about. You've acknowledged that creating forms in background threads is bad, but now the OP has a solution that works whether or not it's a good one. The next time the OP comes upon this situation what do you think he's going to do? The properly desinged way or the quick and dirty way? What do you think he'll promote to his colleagues?

"When Dave says "this is no solution to the problem", he's definitely wrong"

While you're technically correct, I agree with Dave's statement. Application.DoEvents will solve the problem for now, but it's not promoting good design. I did look at the other link where you suggested this and in that case you DID mention to avoid while(true) loops but not here. Just because an answer is technically correct doesn't make it a good answer IMO and that's why I downvoted it.

"having a loop in it will freeze all other threads for the execution time of the loop if you don't call either DoEvents or Sleep"

I was going to let the conversation end but then you made this statement. Take this simple example:

public partial class Form1 : Form
{
private volatile bool runThreads;

public Form1()
{
InitializeComponent();

new Form2().Show();

runThreads = true;

new Thread(() =>
{
while (runThreads)
{
;
}
}).Start();
}

private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
runThreads = false;
}
}

There's a while(true) loop in a background thread and the two forms works just fine. The Windows scheduler will ensure that each thread gets a fair time slice so that the 2 forms will remain responsive. The only way that the previous example can bog down the two forms is when there are so many background threads spinning that it causes the entire system to become unresponsive; sleeping may be appropriate here depending on what the threads are doing but it's moot since this isn't what the OP wants to do. Problems only arise with just one thread when Form2 is created and shown from the background:

public partial class Form1 : Form
{
private volatile bool runThreads;

public Form1()
{
InitializeComponent();

runThreads = true;

new Thread(() =>
{
new Form2().Show();

while (runThreads)
{
;
}
}).Start();
}

private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
runThreads = false;
}
}

Now Form1 works fine but Form2 is hosed because the background thread is busy spinning instead of pocessing window messages. The ONLY solution to make this work is to put an Application.DoEvents inside the body of the loop; sleeping won't accomplish anything because the window can't update if the thread is asleep. Try it and see. Yes. Technically speaking calling Application.DoEvents will work but it's a personal belief that any call to Application.Doevents ia a bad code smell that's an indicator of a lazy design. The MSDN page on Application.DoEvents gives a perfect example of what I mean

Link: http://msdn.microsoft.com/en-us/library/system.windows.forms.application.doevents.aspx

A much better method IMO would have been to load each image, set the picture box and then set a timer to wake up and load the next image. The way it's designed in their sample the app won't respond to ANY user input while the slide show is playing.