We Keep Coding

C# WPF Cmb Text in Textfield with Thread

I´m using the BusyIndicator in my GUI because I have to work with a database that the GUI don´t freeze meanwhile.
private void btnSearch_Click(object sender, RoutedEventArgs e)
{
richSammelbemerkung.Document.Blocks.Clear();
richSammelbemerkung.AppendText("Daten werden gesucht...");
GUIData guiData = new GUIData();
guiData = getInfoFromGUI();
ZeichnungCollection zeichnungen = new ZeichnungCollection();
BackgroundWorker worker = new BackgroundWorker();
busyIndicator.IsBusy = true;
worker.DoWork += (o, ea) =>
{
zeichnungen = searchDrawings(guiData);
};
worker.RunWorkerCompleted += (o, ea) =>
{
Application.Current.Dispatcher.Invoke((Action)(() => CollectionViewSource.GetDefaultView(dataOutOfDb.ItemsSource = zeichnungen).Refresh()));
busyIndicator.IsBusy = false;
if (zeichnungen.Count == 0)
{
MessageBox.Show("Keine Daten gefunden. Eventuell Index überprüfen.", "Info");
}
richSammelbemerkung.Document.Blocks.Clear();
dataOutOfDb.SelectedIndex = 0;
Keyboard.Focus(dataOutOfDb);
};
busyIndicator.IsBusy = true;
worker.RunWorkerAsync();
}
It´s look like this.
Before I put the BusyIndicator into my GUI I just run the code and used the SelectionChanged of the Cmb to set the selected Text into a Textfield.
The problem I have now is, that when the SelectionChanged is fired it throws a Exception even if I used a IF to ask for elements.
So I went on with DataBinding like this:
Text="{Binding ElementName=cmbTag, Path=SelectedItem}"
Now when it doesn´t throw a exception or anything else.
BUT, I can´t set a new value in the Textfield because it automatically refreshes on what is selected in the Combobox.
So, has anyone an idea how I can set the selected value from the Cmb to the Textfield without using SelectionChanged or DataBinding, or even so that it doens´t throw a exception?

This has nothing to do with the BusyIndocator.
The problem is that you want to access the UI from another thread. But any operation with the UI must be made from the UI-Thread.
In your example anything within the DoWork method (which runs in another thread) can not access the UI. You'll get an exception or Bindings won't work.
You can use a Dispatcher within the DoWork method to track the code back to the UI Thread, like this:
Application.Current.Dispatcher.Invoke(() => {
// this code will run in the UI Thread again
});
But I think it's more elegant to remove all UI manipulation from the DoWork Action or use the BackgroundWork's ReportProgress Method for that.

C# - How to work with background worker with custom code -Run,Pause,Stop?

I am working with Background Worker but neither i am able to synchronize my progress bar nor able to stop or abort the process.
in my dowork function
void bw_DoWork(object sender, DoWorkEventArgs e)
{
if(bw.CancellationPending==true)
{
e.cancel=true;
return;
}
else
{
e.Result = abc();
}
}
int abc()
{
//my work
Count++;
return count;
}
void bw_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
if(bw.CancellationPending==true)
{
button17.Visibility = Visibility.Visible;
label1.Content = "Aborted";
}
button17.Visibility = Visibility.Visible;
label1.Content = "Completed";
}
private void Cancel_Click(object sender, RoutedEventArgs e)
{
if(bw.IsBusy)
{
bw.CancelAsync();
}
}
Now i want to know how could i Synchronize my Progress Bar and how to exit from the process?

Have you set the BackgroundWorker.WorkerReportsProgress && BackgroundWorker.WorkerSupportsCancellation properties on your instance to be true?
e.g.
var myBackgroundWorker = new BackgroundWorker();
myBackgroundWorker.WorkerReportsProgress = true;
myBackgroundWorker.WorkerSupportsCancellation = true;
//the rest of the init
If you want to report progress, you need to call the BackgroundWorker.ReportProgress() method from inside your DoWork.

This is a rubbish and trivial answer but give the Task Parallel library a whirl.
http://msdn.microsoft.com/en-us/library/dd537608.aspx
This library encapsulates threads as discrete Task objects. It supports cancellation.
Be warned that in a worker thread, pause and cancellation operation have to be supported by the worker code itself, by polling pause/cancel flags and tokens. You cannot safely achieve these operations with threads alone.
It is a nicer pattern to work with
As for your question, 2 flags are required to support your operations. You will be need to check them at intervals during the worker code.
bool pause = false;
bool cancel = false;
void DoWork()
{
try
{
...
//periodically check the flags
if(cancel) return;
while(paused){}; //spin on pause
...
}
finally
{
//cleanup operation
}
}
Alastair Pitts' answer illustrates how background worker supports these features.
So does MSDN ;) http://msdn.microsoft.com/en-us/library/cc221403%28v=vs.95%29.aspx

(You might want to check out this other SO question/answer for details about the new async facility! It greatly improves the quality of life of developing this kind of operations!)
BackgroundWorker is event-based, basic usage is the following (the link provides many useful additional details):
var worker = new BackgroundWorker();
// The following two props must be true:
// #1: The worker will be enabled to signal its progress
worker.WorkerReportsProgress = true;
// #2: The worker will accept cancellation
worker.WorkerSupportsCancellation = true;
// Now the events:
worker.DoWork += (s,e) =>
{
int i = 0; // This goes from 0 to 100
// Do code, update 'i'
worker.ReportProgress(i);
worker.CancelAsync(); //... to cancel the worker if needed
// WARNING: This code *cannot* interact with the UI because
// it's running in a different thread
};
worker.ProgressChanged += (s,e)=>
{
// This is executed when you call ReportProgress() from DoWork() handler
// IMPORTANT: All UI interaction **must** happen here
// e.ProgressPercentage gives you the value of the parameter you passed to
// ReportProgress() (this mechanism is a perfect fit for a progress bar!)
};
worker.RunWorkerCompleted+= (s,e) =>
{
// code here runs when DoWork() is done, is canceled or throws.
// To check what happened, the link provides this sample code:
if (e.Cancelled == true)
{
// Cancelled!
}
else if (e.Error != null)
{
// Exception !
}
else
{
// Work completed!
}
};
worker.RunWorkerAsync();
It's important to know that (extracted from the link above):
You must be careful not to manipulate any user-interface objects in your DoWork event handler. Instead, communicate to the user interface through the ProgressChanged and RunWorkerCompleted events.
UPDATE Lambdas here are used to keep code compact. You can obviously use "normal" handlers or whatever other method of attaching code to events you like/want/need.

How do I run task like `object = ClassA.GetObject()` in a separate thread using BackgroundWorker?

I'm trying to make this line to work with BackgroundWorker:
map = Map.LoadMap(mapname);
…like this:
bw.DoWork += (map = Map.LoadMap(mapname));
It causes the error Cannot implicitly convert type 'game.Map' to 'System.ComponentModel.DoWorkEventHandler'.
I just started using BackgroundWorker as threading component for my game, but it doesn't look like it will be easy to convert all existing methods to work with it. Is there a simple way to make this work or is it better to switch to some other threading mechanism?
Note: from the threading base I need to be able to poll for progress percentage and not messing up my existing method calls.

You can leverage anonymous delegates like this:
bw.DoWork += (sender, args) => { map = Map.LoadMap(mapname); };

As I understand the type of variable map and the return type of method Map.LoadMap - are game.Map.
In your code in line
bw.DoWork += (map = Map.LoadMap(mapname));
you are doing next: get the result from Map.LoadMap(mapname), set it to variable map and after that try to use this value as a handler for DoWork event. And the type of variable map and property bw.DoWork are different.
So you just need to change this line to:
bw.DoWork += (sender, eventArgs) => { map = Map.LoadMap(mapname); }
Which will mean that you are trying to create new Delegate "(sender, eventArgs) => ..." and use it as a handler for property bw.DoWork.

Backgroundworker is good because you can use the option WorkerReportsProgress = true
this can be used to pool for a percentage
you can report progress inside the DoWork method like this
bw.ReportProgress(percentage);
I use to associate BackgroundWorker as a wrapper for what Threads would do. So I use BackgroundWorker on GUI works, and Threads on more specialized or dirty jobs (Windows Services, etc)
you dowork method has to be written like this
bw.DoWork += (sender, args) => { map = Map.LoadMap(mapname); };

You can use the BackgroundWorker like this:
var worker = new System.ComponentModel.BackgroundWorker();
worker.DoWork += delegate
{
map = Map.LoadMap(mapname);
};
worker.RunWorkerAsync();
Keep in mind that the program will continue execution immediatly after the RunWorkerAsync() method so if you use the map variable afterwards it will probably not be a loaded map.
To continue execution after the map has been loaded you need to subscribe to the RunWorkerCompleted also:
var worker = new System.ComponentModel.BackgroundWorker();
worker.DoWork += delegate
{
map = Map.LoadMap(mapname);
};
worker.RunWorkerCompleted += delegate
{
MapComplete(); // contiune with stuff here
};
worker.RunWorkerAsync();

The += operator indicates that you are attaching an event handler (DoWork is an event).
Here is an example usage:
Create an instance of the backgroundworker(in this case it will be at the class level), call the function that attaches the events SetupBackgroundWorker()
private BackgroundWorker bw = new BackgroundWorker();
private void SetupBackgroundWorker()
{
bw.DoWork += new DoWorkEventHandler(bw_DoWork);
bw.RunWorkerCompleted += new RunWorkerCompletedEventHandler(bw_RunWorkerCompleted);
bw.ProgressChanged += new ProgressChangedEventHandler(bw_ProgressChanged);
bw.ReportProgress = true;
}
These are sample event handlers, should give you an idea
private void bw_ProgressChanged(object sender, ProgressChangedEventArgs e)
{//Just as an example, I don't ever call the functions to trigger this event
int ProgressPercent = e.ProgressPercentage;
object AnyOtherDataReported = e.UserState;
}
private void bw_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
//Do something when the work has been completed
//Note: You should always check e.Cancelled and e.Error before attempting to touch the e.Result. I did not put that protection in this example.
object TheResultFrom_DoWork = e.Result;//This is your "map" object
}
private void bw_DoWork(object sender, DoWorkEventArgs e)
{
//object PassedInObject=e.Argument; //This is the argument you sent to RunWorkerAsync
//Type cast PassedInObject to your correct Type
WhateverTypeItIs_YouDidntSay mapname=(WhateverTypeItIs_YouDidntSay)e.Argument
//Perform your task
object returnvalue=Map.LoadMap(mapname);//This was your varriable called "map"
//Assign the result of your task to the return value
e.Result=returnvalue;
}
Pass this function the value for mapname and if the backgroundworker is not busy doing a previous task, it should start the process.
private void ProcessTheMap_InBackground(WhateverTypeItIs_YouDidntSay mapname)
{
if (!bw.IsBusy)
{
bw.RunWorkerAsync(mapname);
}
else
{//You are already loading something in the background
}
}

CrossThreading issue with BackgroundWorker and statusstrip update

I have been working on a tool that uses a BackgroundWorker to perform a ping operation on a regular interval. I am running into an issue with the BackgroundWorker ProgressChanged event. The code for the ProgressChanged Event is below:
private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
ProgressUpdated update = (ProgressUpdated)e.UserState;
if (sender.ToString() == "System.ComponentModel.BackgroundWorker")
{
toolStripStatusLabel1.Text = update.GeneralStatus;
toolStripProgressBar1.Value = update.ProgressStatus;
toolStripStatusLabel2.Text = update.SpecificStatus;
}
else
{
toolStripStatusLabel1.Text = update.GeneralStatus;
toolStripProgressBar2.Value = update.ProgressStatus;
toolStripStatusLabel3.Text = update.SpecificStatus;
}
}
The ProgressChanged event gets called both in the BackgroundWork where it updates the first values and from the pingcompletedcallback event when a ping finishes. I only run into the cross threading issue when the ProgressChanged event runs from the PingCompletedCallback event. It throws the error when it goes to update the second Progress bar.
I can not seem to figure out why its happening for one of the calls but not the other.
Is the PingCompletedCallBack happening on the BackgroundWorker thread and thats why its causing the cross threading issues?
If so how do I raise the event so that it will be processed on the UI thread and not the backgroundworker?
Edit:
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
BackgroundWorker worker = sender as BackgroundWorker;
// creates ping and sends it async
ProgressUpdated args = new ProgressUpdated(string1, int1, string 2);
worker.ReportProgress(0,args);
// rest of thread for cleanup when cancellation is called
}
private void PingCompletedCallback(object sender, PingCompletedEventArgs e)
{
// handle the ping response
ProgressUpdated update = new ProgressUpdated(string1, int1, string2);
ProgressChangedEventArgs changed = new ProgressChangedEventArgs(1,update);
backgroundWorker1_ProgressChanged(this, changed);
// handle other types of responses
}
I thought the use of events was to allow the separation of threads. Aka worker thread raises an event that the UI thread is listening for, then the raised event gets processed on the UI thread.
Since my understanding was wrong, would the PingCompletedCallBack have access to the the ReportProgress method of the backgroundworker?
I could then change in PingCompletedCallback:
ProgressChangedEventArgs changed = new ProgressChangedEventArgs(1,update);
backgroundWorker1_ProgressChanged(this, changed);
to:
backgroundWorker1.ReportProgress(1, update);
or would I need to change it in some other way?
Thanks for anyone's assistance.
Edit 2:
Changed ProgrssChanged event
private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
ProgressUpdated update = (ProgressUpdated)e.UserState;
toolStripStatusLabel1.Text = update.GeneralStatus;
toolStripProgressBar1.Value = update.ProgressStatus;
toolStripStatusLabel2.Text = update.SpecificStatus;
}
I then created a second update event
private void PingUpdate (object sender, ProgressUpdated e)
{
toolStripStatusLabel1.Text = e.GeneralStatus;
toolStripProgressBar2.Value = e.ProgressStatus;
toolStripStatusLable3.Text = e.SepcificStatus;
}
The only thing I have left is to call the new event from PingCompletedCallback in such a way as it gets executed on the UI Thread. Is this where the Invoke statement would be used or should the Invokes be used in the new event?

The documentation for BackgroundWorker states that you should not be manipulating UI objects through the DoWork method, and that any changes to UI objects should be made through ReportProgress. I haven't looked at reflector, but it's probably performing a hidden "Invoke" for you. Whatever is raising your PingCompleted event is probably executing within the worker thread or some other thread that is not the main thread.
You will see in the threads window of the Visual Studio debugger that DoTask does not execute on the main thread; however, when ReportProgress is called, the handler is executed on the main thread. Since your controls were probably created on the main thread, you do not see the exception.
Now, if you attempt to call backgroundWorker1_ProgressChanged explicitly within the DoWork method, then backgroundWorker1_ProgressedChanged will be executed on the same thread that's executing the DoWork method, or, in your case, the method that's raising the PingCompleted event:
You can probably solve this cross thread exception by adding InvokeRequired checks within your backgroundWorker1_ProgressChanged handler, or route your PingCompleted handler to call ReportProgress
EDIT:
Calling ReportProgress from the PingCompleted handler won't work because you will lose the original sender.
private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
if (InvokeRequired)
{
Invoke(new ProgressChangedEventHandler(backgroundWorker1_ProgressChanged), sender, e);
return;
}
// The rest of your code goes here
}
EDIT 2 Response:
private void PingUpdate (object sender, ProgressUpdated e)
{
if (InvokeRequired)
{
Invoke(new Action<object, ProgressUpdated>(PingUpdate), sender, e);
return;
}
toolStripStatusLabel1.Text = e.GeneralStatus;
toolStripProgressBar2.Value = e.ProgressStatus;
toolStripStatusLable3.Text = e.SepcificStatus;
}

This BackgroundWorker is currently busy and cannot run multiple tasks concurrently

I'm trying to use a Background Worker in a WPF application. The heavy lifting task uses WebClient to download some HTML and parse some info out of it. Ideally I want to do that downloading and parsing without locking the UI and placing the results in the UI once it's done working.
And it works fine, however, if I quickly submit the "download and parse" command, I get the error:
This BackgroundWorker is currently busy and cannot run multiple tasks
concurrently
So I did some Googling and it seems that I can enable the .WorkerSupportsCancellation property of the background worker and just .CancelAsync(). However, this doesn't work as expected (canceling the current download and parse).
I still get the above error.
Here's my code:
//In window constructor.
_backgroundWorker.WorkerSupportsCancellation = true;
_backgroundWorker.DoWork += new DoWorkEventHandler(_backgroundWorker_DoWork);
_backgroundWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(_backgroundWorker_RunWorkerCompleted);
//Declared at class level variable.
BackgroundWorker _backgroundWorker = new BackgroundWorker();
//This is the method I call from my UI.
private void LoadHtmlAndParse(string foobar)
{
//Cancel whatever it is you're doing!
_backgroundWorker.CancelAsync();
//And start doing this immediately!
_backgroundWorker.RunWorkerAsync(foobar);
}
POCOClassFoo foo = new POCOClassFoo();
void _backgroundWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
//This automagically sets the UI to the data.
Foo.DataContext = foo;
}
void _backgroundWorker_DoWork(object sender, DoWorkEventArgs e)
{
//DOING THE HEAVY LIFTING HERE!
foo = parseanddownloadresult()!
}

Calling CancelAsync will still fire the RunWorkerCompleted event. In this event, you need to make sure that CancelAsync has not been called, by checking e.Cancelled. Until this event fires, you cannot call RunWorkerAsync.
Alternatively, I would recommend you do what Tigran suggested and create a new BackgroundWorker each time.
Further more, I would recommend storing the results of_backgroundWorker_DoWork in e.Result, then retrieve them from the same in _backgroundWorker_RunWorkerCompleted
Maybe something like this
BackgroundWorker _backgroundWorker;
private BackgroundWorker CreateBackgroundWorker()
{
var bw = new BackgroundWorker();
bw.WorkerSupportsCancellation = true;
bw.DoWork += _backgroundWorker_DoWork;
bw.RunWorkerCompleted += new _backgroundWorker_RunWorkerCompleted;
return bw.
}
private void LoadHtmlAndParse(string foobar)
{
//Cancel whatever it is you're doing!
if (_backgroundWorer != null)
{
_backgroundWorker.CancelAsync();
}
_backgroundWorker = CreateBackgroundWorker();
//And start doing this immediately!
_backgroundWorker.RunWorkerAsync(foobar);
}
//you no longer need this because the value is being stored in e.Result
//POCOClassFoo foo = new POCOClassFoo();
private void _backgroundWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
if (e.Error != null)
{
//Error handling goes here.
}
else
{
if (e.Cancelled)
{
//handle cancels here.
}
{
//This automagically sets the UI to the data.
Foo.DataContext = (POCOClassFoo)e.Result;
}
}
private void _backgroundWorker_DoWork(object sender, DoWorkEventArgs e)
{
//DOING THE HEAVY LIFTING HERE!
e.Result = parseanddownloadresult()!
}

The thing is that CancelAsync() does what it climes: cancel in async way. That means that it will not stop immediately, but after some time. That time can never be calculated or predicted, so you have a couple of options:
Wait until this backround worker stops really, by waiting in cycle until IsBusy property of it becomes false
Or, I think, better solution is to start another background worker, considering that request of cancelation was already sent to the first one, so it will be soon or later stop. In this case, you need to know from which background worker data comes, in order to process it or not, cause on start of second the first one will still run and pump the data from WebService.
Hope this helps.

CancelAsync returns before the worker cancels and stops its work. Hence, your RunWorkerAsync call is starting before the worker is ready, and you're getting that error. You'll need to wait for the worker to be ready first.

When I'm not interested in tracking progress of an async operation, I tend to prefer to just slap a lambda at ThreadPool.QueueUserWorkItem instead of instantiating and setting up a background worker that I have to check the state of to be able to reuse in a sane way.

You need to verify before you kicks in.
f( !bw.IsBusy )
bw.RunWorkerAsync();
else
MessageBox.Show("Can't run the bw twice!");

You are calling CancelAsync without waiting for the background worker to actually cancel the work. Also you must have your own logic for cancelling the work. There is a good example on MSDN which shows how to do it. Basically in your parseanddownloadresult() method you need to check the CancellationPending property.