.NET Questions (CLOSED)

Questions and Answers on any aspect of .NET. Now closed.

This discussion group is now closed.

Have a question about .NET development? Try stackoverflow.com, a worldwide community of great developers asking and answering questions 24 hours a day.

The archives of .NET Questions contain years of Q&A. Even older .NET Questions are still online, too.

forms controls are disabled during processing

Hi when i click the button in windows forms the button calls the function but the the other controls in the forms are not released untless and untill the function completes the processing what if some person wants to terminate the process  abnormally for some reason he culd'nt.... can any one tell me out how to getrid of the problem.......

private void startProcess_Click(object sender, EventArgs e)
{
 someoclass obj = new someclass();
 obj.StartProcess(cmbid.Text);       
this.Hide();
frmRemobaSyncSetup9 frm9 = new frmRemobaSyncSetup9();
frm9.ShowDialog();
}


when i click the start process button it executes the function the process takes around 15 sec to complete but i shul'd give the provision for user to abnormally terminate.... but when i click the START PROCESS BUTTON THE CONTOLS IN THE FORMS ARE NOT RELEASED/ACTIVE until unless processs is completed...... is there anything i am missing or any api in VISUAL C# that helps me over come this problem??????

Thankyou
newbie
Tuesday, January 23, 2007
 
 
outshider
Tuesday, January 23, 2007
 
 
This is normal behavior for ANY windows application. The windows message loop which process messages is single threaded. So your other controls can't process subsequent messages until the first one (your button click event) is done.

As the previous poster implied, you need to run your time consuming functions on another thread. The easiest way to do this is to use the BackgroundWorker component (see the link above).
anon
Tuesday, January 23, 2007
 
 
And just in case someone else posts it as a "solution", I will tell you now not to use DoEvents. It is evil and can cause you all kinds of problems. The correct way to handle this problem is with another thread (BackgroundWorker).
anon
Tuesday, January 23, 2007
 
 
Any suggestions y not to use DoEvents i am using it and have no problem
sudhakar Send private email
Tuesday, January 23, 2007
 
 
and i was also using it before in visual basic
sudhakar Send private email
Tuesday, January 23, 2007
 
 
DoEvents causes your code to be re-entrant. If your code is not made to handle this then you have problems. If you are in the middle of a tight loop and the DoEvents call is because someone closed the form, then you can get errors because objects may have been disposed of by the time your loop gets control back. Other weird problems can occur with form level variables and flags values due to events not being called in the order you expect.

Think of it this way, DoEvents causes FUTURE events to be processed ahead of the current event. So this can really mess up your program if you don't catch every little case where it can trip you up. Using a BackgroundWorker is much safer and is the suggested approach.

Another trick you can use is to call the Refresh method on individual controls if you are just looking for UI update capability during a long loop (want to update a label with processing results, etc.).
anon
Tuesday, January 23, 2007
 
 
Using DoEvents vs. using BackgroundWorker really ends up being the same amount of code. Using BackgroundWorker requires you to disable the UI just like you have to do with DoEvents unless you want the user to be able to trigger the same opperation multiple times. The user can also attempt to close the form when using BackgroundWorker so you have to catch this as well. So the code ends up being roughly the same for both techniques.

The REAL reason why DoEvents is evil is because so many programers just don't understand how it works. They don't recongnize the reentrancy issue and just assume that DoEvents cause the screen to repaint properly. It does much more than that. It processes every windows message in the queue before returning back to the original calling point. These messages are not restricted to paint messages. They can be mouse, keyboard, menu, and any other type of windows message available. This means that the whole form can close which includes running any close down code that you have before your original event gets control back. If you aren't prepared for this then you can have subtle bugs in your code.

So I personally prefer BackgroundWorker because it already has support for cancellation and it naturally makes the programmer realize that multi-threading is going on. Although DoEvents is technically not multi-threading, it has some of the same pitfalls and these aren't readily apparent to most programmers.
dood mcdoogle
Tuesday, January 23, 2007
 
 
hi guys i followed the ex as u said but i am getting the exception below am not able to figure it out this exception comes when i click cancel event during processing


This BackgroundWorker states that it doesn't support cancellation.
Modify WorkerSupportsCancellation to state that it does support cancellation.


Thanks,
newbie
Tuesday, January 23, 2007
 
 
Set the WorkerSupportsCancellation property of the BackgroundWorker to true. It is false by default. You will probably also want to set the WorkerSupportsProgress property to true as well if you want to use the progress update capability.
dood mcdoogle
Wednesday, January 24, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz