I work on WinForms app (VB.NET) which handles CRUD operations. When it loads the data, it seems state like \"Not Responding\" and when loading finished, every thing will be norm
All windows apps are such that if you execute any lenghty operation from your events you'll get 'not responding' for some period of time, because program isn't responding to the rest of the system. You have several options here:
If you will use second options, make sure that you don't update anything on UI directly, because it will break, use Invoke() instead.
If you are using a single interface, it is ideal to use Application.DoEvents()
. If you have one form that does a sequence of tasks when you click a button, then you're using a single interface.
Why Application.DoEvents()?
From the MSDN page on DoEvents():
When you run a Windows Form, it creates the new form, which then waits for events to handle. Each time the form handles an event, it processes all the code associated with that event. All other events wait in the queue. While your code handles the event, your application does not respond. For example, the window does not repaint if another window is dragged on top.
If you call DoEvents in your code, your application can handle the other events. For example, if you have a form that adds data to a ListBox and add DoEvents to your code, your form repaints when another window is dragged over it. If you remove DoEvents from your code, your form will not repaint until the click event handler of the button is finished executing. For more information on messaging, see User Input in Windows Forms.
In a nutshell, if you click a button and have to wait for some work to be done, Application.DoEvents()
will refresh the form UI and get rid of the (not responding) issue.
How to use DoEvents() The same MSDN page also states that
Typically, you use this method in a loop to process messages.
So, the easiest way to tell where it should go is to look for a loop in your program where a lengthy operation occurs and place Application.DoEvents()
inside that loop. I typically place it right at the end inside said loop.
For example:
foreach (var foo in bar)
{
// Do work
Application.DoEvents();
}
Why Not BackgroundWorker for a Single Interface?
When you create multiple threads where multithreading is not needed, you leave the possibility of thread leak. For example, if you implement a BackgroundWorker to handle the CRUD operations but then, for some reason, close out the program, the interface will close but the backgroundworker thread will keep running. You can confirm that this process is still running via task manager.
BackgroundWorkers are ideal when you have other devices in play, such as printers. That is, you probably wouldn't want your program to halt until it's finished printing a document; for that reason, a new thread can handle the print job while you continue to use your program.
You could use a BackgroundWorker to offload lengthy operations on a background thread to avoid blocking the main UI thread.