In WPF, I am calling
This.Dispatcher.BeginInvoke(DispatcherPriority.SystemIdle, mydelegete);
Is there a way to cancel later that BeginInvoke method?
Thanks
Dispatcher.BeginInvoke returns a DispatcherOperation object. If you retain a reference to it, you can use its Abort method to dequeue the operation if it hasn't started executing yet.
Related
I have implemented a WPF application using background worker in which I am assigning data from database to combobox.
I have used observable collection as ItemSource for combobox .
When I try to fill up the observable collection in DoWork method of background worker, UI is not getting updated but if I move same code to ProgressChanged or RunWorkerCompleted then it is working fine.
I want to know why the DoWork method is not updating the UI.Also the logic for updating UI should be in ProgressChanged or RunWorkerCompleted?
To quote MSDN : "You must be careful not to manipulate any user-interface objects in your DoWork event handler" - so in your DoWork method call ReportProgress event and update your ui in the ProgressChanged event handler
There are many online examples showing how to correctly utilise a BackgroundWorker. As you haven't bothered to show us your code, all we can do is guess, but I'm guessing that you simply haven't implemented your code properly. Not wanting to duplicate this code once again, I'd rather advise you to take a look at my answer to the Progress Bar update from Background worker stalling question here on Stack Overflow.
It clearly demonstrates how to implement a BackgroundWorker correctly.
Im reading a WPF book and I see this code:
private void bgw1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
int percenti;
percenti = e.ProgressPercentage;
progressBar1.Value = percenti;
}
The question is simple.
if
ProgressBar belongs to UI Thread and
BackGroundWorker works with a Background Thread
Why are there no errors (like: The calling thread cannot access this object because a different thread owns it.)?
thanks.
Why are there no errors (like: The calling thread cannot access this object because a different thread owns it.)?
This is one of the main advantages to using BackgroundWorker. The BackgroundWorker component automatically marshals calls for progress and completion back to the synchronization context (thread) that starts the job.
In this case, that means that the event handlers for ProgressChanged (and the completion event) happen on the WPF UI thread.
The BackgroundWorker handles the thread context switch for you. The event BackgroundWorker.ProgressChanged will be raised on the UI-Thread and hence your callback bgw1_ProgressChanged will be called in the context of the UI-Thread.
This was the main purpose for the BackgroundWorker's existence: To make async work easy and straight forward in conjunction with a UI.
BackgroundWorker exists since .NET 1.0. Now that we live in 2012, we have the Task class and the Task Parallel Library and soon the c# async keyword as general means for everything async, wich makes the BackgroundWorker kind of obsolete or at least old school.
It is because you cannot make changes in the Do_work method of the background worker.
progress_changed event keeps updating what is happening in the other thread.
Bes to clear your concept through this link-->
[https://www.codeproject.com/Articles/99143/BackgroundWorker-Class-Sample-for-Beginners][1]
I know that Dispatcher.BeginInvoke is needed whenever I'm updating the GUI on a background thread. But how do I determine at runtime if it is needed?
Call Dispatcher.CheckAccess.
Is there an event for onAbort for the backgroundworker control?
I don't believe so. When you call CancelAsync on the BackgroundWorker you need to handle the cancellation yourself. This then gets passed through to the RunWorkerCompleted event, however you can tell that it was cancelled through e.Cancelled.
there is no specific event for "Cancel event".
You really should look at the MSDN documentation: http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.runworkercompleted.aspx
I have been trying to get a progressbar set to marquee to keep moving while another function is running. After this function runs, I message would display (for this example)
The only way I was able to get this working was with a background worker and then have a
Do
Loop until condition that runs in the main form until the operation is complete followed by my message box.
This seems like a kludge way to accomplish this and a thread.start followed by a thread.join seems like a much nicer way to fix this. However, I was not able to get that working either.
I have included a small demo program if anyone is interested.
http://www.filedropper.com/progressbar
Thanks
Thread.Start and Thread.Join is not the way to do it - that basically blocks your UI thread again. Application.DoEvents isn't the way to go either - you really do want a separate thread.
You could then use Control.Invoke/Control.BeginInvoke to marshal back to the UI thread, but BackgroundWorker makes all this a lot easier. A search for "BackgroundWorker tutorial" yields lots of hits.
EDIT: To show the message when the worker has finished, use the RunWorkerCompleted event. The ReportProgress method and ProgressChanged event are used to handle updating the progress bar. (The UI subscribes to ProgressChanged, and the task calls ReportProgress periodically.)
That is not a kludge. That is the correct way of doing it; what happens with the BackgroundWorker approach? The trick is to use the ReportProgress method to push the change back to the UI (don't update the ProgressBar from the worker).
Use Application.DoEvents() in your function from time to time so that your process has some time to process his events, including redrawing the form.
Alternatively, you can use a worker thread (like a BackgroundWorker) to process your treatement, while the UI thread is displaying your progress bar.
Complementing the answer given by Marc Gravell, the BackbroundWorker has a boolean property WorkerReportsProgress, if it is set to false, when you call ReportProgress, the program will raise an InvalidOperationException