I'm working in a c# windows application with vs2010 and a local database.In one of my forms i use a BindingNavigator with a group of textboxes filled by the database and a ReporViewer. I've added a background worker in order to fill the table adapters in case there are a lot of records in the database.
The problem is that the way I'm using the background worker when i debug my app i cannot see any data in the textboxes, otherwise when i run my app it's working fine. I know that this is a case of accessing the UI on a non-UI thread and it is wrong. Is there a another way around it?Thank you in advance.
Here is the code I'm using:
private void Client_Load(object sender, EventArgs e)
{
backgroundWorker1.RunWorkerAsync();
}
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
this.clientTableAdapter.Fill(this.database1DataSet.Client);
this.projectTableAdapter.Fill(this.database1DataSet.Project);
if (InvokeRequired)
{
this.Invoke(new MethodInvoker(this.reportViewer1.RefreshReport));
return;
}
}
Typically, a background worker returns on the same thread, and would actually throw an exception about the non-UI thread. However, this might be eaten in your case. You should be using the RunWorkerCompleted event for items that are to happen after your main work is done, especially when looking to update the UI. And, this should return to the same thread it was called from (UI in your case) as mentioned above.
So, I would move your UI processing code (RefreshReport) into a new method set up for the RunWorkerCompleted.
However, my suggestion would be to take a look at the Task Parallel Library. It ends up making code much cleaner and easier to debug IMO.
Example (rough and may not compile due to the nulls, but you can get the jist :)):
var task = Task.Factory.StartNew(()=>{//Do Async Stuff});
task.ContinueWith((previousTask)=>{//Do your UI Stuff}, null, null,
TaskScheduler.FromCurrentSynchronizationContext);
//The FromCurrentSync makes sure the method returns
//to the same thread (UI in this case) that it started
I know that is not a direct answer, but more of a suggestion towards what I would consider a cleaner, more debuggable approach.
Related
I'm currently building an app that relies on DataGridView to receive updates via WAMP protocol, which involves working with new message events. My event handler looks like this:
private async void NewMessage(object sender, MessageEventArgs e)
{
await Task.Factory.StartNew(() => DataHolder.TableSource.Add(new
CustomData(e.Name, e.Surname,
e.Whatever, e.WhoTheHellCares)));
}
When such an event occurs, an exception is thrown: System.InvalidOperationException "An attempt to access control element which was created in a different thread".
DataHolder is a static class that exists within same namespace with the form class that has this event handler, DataHolder.TableSource is a BindingList<T> which is bound in Form.Load event to the DataGridView control created in Form1.Designer.cs .
I've read an answer to a related issue here, that mentioned await being able to automatically marshall something to UI thread if needed, but my wild and incompetent guess is that await does not recognize a databinding, so it must be told explicitly to do so, how though?
I need a .net 4.5 solution here or proof that tasks and awaits are unable to solve my problem. But I think they are more than able. Just that I have trouble to apply it to my own situation here.
UPDATE
Wow, what the hell.. Even when my handler looks like this, it still gives me the same exception.
private void NewMessage(object sender, MessageEventArgs e)
{
DataHolder.TableSource.Add(new
CustomData(e.Name, e.Surname,
e.Whatever, e.WhoTheHellCares));
}
I guess it has something to do with the class itself that is firing an event. Well.. I tried D:
UPDATE
I've used debugging tools and here's the deal - the event itself is already nested in another thread. Will try to rewrite the source code for the library I'm using so that it will support progress reports. Wish me f`kin luck D:
An attempt to access control element which was created in a different thread
The issue is that your code is touching a UI element (or something that it relies on) from something other than the main UI thread. You must not do this.
I know that you don't want to use Invoke but it really is the way to solve this problem. These links (and hundreds like it) discuss it:
How to update the GUI from another thread in C#?
Can you access UI elements from another thread? (get not set)
Cross-thread operation not valid: Control accessed from a thread other than the thread it was created on
Based on your comment, another approach you could consider is Looking for .NET 4.5 Progress<T> source code . Have a look at how it uses SynchronizationContext .
You are misunderstanding async/await.
Your method will be divided in 2 parts: the before await and the after await. So when code runs it will execute like this:
before await
AWAIT IN ASYNC THREAD
execute your awaited method (what is inside Task.StartNew) in another thread(not necessarily)
When step 3 is complete it will wakeup (marshal) the execution of step 2
run after await
So what is happening is that what is being marshaled to UI thread is the execution of the second part of your method not what is inside the task.
There is more to it than this, but I think this is the steps I used to understand it.
To solve this remove async completely as you are not doing a long process:
private void NewMessage(object sender, MessageEventArgs e)
{
DataHolder.TableSource.Add(new CustomData(e.Name, e.Surname,
e.Whatever, e.WhoTheHellCares));
}
Or if you want to be async and you are in a WinForms control use BeginInvoke
private void NewMessage(object sender, MessageEventArgs e)
{
this.BeginInvoke((Action)(() => DataHolder.TableSource.Add(new
CustomData(e.Name, e.Surname,
e.Whatever, e.WhoTheHellCares))));
}
I have a windows forms application
on which I need to use a for loop having a large number of Remote Calls around 2000 - 3000 calls,
and while executing the for loop, I loose my control on form and form controls, as it becomes a large process and some time it shows "Not Responding" but if I wait for a long it comes back again, I think I need to use some threading model for that, is there any idea, how can I proceed to solve the issue?
You need to perform the long running operation on a background thread.
There are several ways of doing this.
You can queue the method call for execution on a thread pool thread (See here):
ThreadPool.QueueUserWorkItem(new WaitCallback(YourMethod));
In .NET 4.0 you can use the TaskFactory:
Task.Factory.StartNew(() => YourMethod());
And in .NET 4.5 and later, you can (and should, rather than TaskFactory.StartNew()) use Task.Run():
Task.Run(() => YourMethod());
You could use a BackgroundWorker for more control over the method if you need things like progress updates or notification when it is finished. Drag the a BackgroundWorker control onto your form and attach your method to the dowork event. Then just start the worker when you want to run your method. You can of course create the BackgroundWorker manually from code, just remember that it needs disposing of when you are finished.
Create a totally new thread for your work to happen on. This is the most complex and isn't necessary unless you need really fine grained control over the thread. See the MSDN page on the Thread class if you want to learn about this.
Remember that with anything threaded, you cannot update the GUI, or change any GUI controls from a background thread. If you want to do anything on the GUI you have to use Invoke (and InvokeRequired) to trigger the method back on the GUI thread. See here.
private voidForm_Load(object sender, EventArgs e)
{
MethodInvoker mk = delegate
{
//your job
};
mk.BeginInvoke(callbackfunction, null);
}
private void callbackfunction(IAsyncResult res)
{
// it will be called when your job finishes.
}
use MethodInvoker is the easiest way.
Obviously, you need to use background threads. I suggest you read this free e-book.
I'm a bit of a newbie at this but I am trying to get the UI on a Reversi game to run on a different thread to the move selection part but I am having some trouble calling the thread on the button click
private void playerMoveOKButton_Click(object sender, EventArgs e)
{
ReversiT.Invoke();
}
public void ReversiT() {...}
If you're trying to create a new thread, you can do something like this:
Thread thread = new Thread(ReversiT);
thread.Start();
Invoke is used for a different purpose though. It is used to run a method on a specific thread (for instance, if you run a piece of code on a separate thread but want to make UI changes, you will want to use Invoke to make those changes on the UI thread)
I would create a BackgroundWorker to handle everything for me, setting it's DoWork event to call your move method (making sure that your move method doesn't touch the UI, or if it has to, invoking the controls on the UI thread).
I'd also set up a method to update the UI on the BackgroundWorker's RunWorkerCompleted event.
Now on your button click event above, call the BGW's RunWorkerAsync() method.
You can not invoke a method like that. You can only invoke delegates. Also, calling Invoke doesn't spawn a new thread.
You can read this tutorial about delegates, and this one about threads. Also, your question leaves much space for discussion:
What do you expect from using threads?
Have you considered different options for doing background work?
etc.
Use following
this.Invoke(ReversiT);
I think you need to think about that you are actually trying to achieve here. Running code on a separate thread in a UI is a technique used to stop the UI from hanging. However, some tasks simply have to occur on the UI thread and so can't be run from another thread.
You need to break your logic out such that you can identify which parts need to run on the UI thread (anything that interacts with a control on your UI) and thus anything that can run on a separate thread.
You would end up with code like (as an example):
private void playerMoveOKButton_Click(object sender, EventArgs e)
{
//thread is merely used as an example
//you could also use a BackgroundWorker or a task
var thread = new Thread(NonUiLogic);
thread.Start();
}
private void NonUiLogic()
{
...
//execute logic that doesn't touch UI
...
BeginInvoke(ReversiT);
}
public void ReversiT() {...}
Once you have been through that exercise you may find that there is actually very little that can happen outside of the UI thread and so you really have nothing to gain from using threads.
I have a multi threaded app where I have created a Producer/Consumer Pattern for the processing of XML files etc
What I want to know is what would be a good approach for updates to the UI and when the process finshed.
Should I go down a threaded approach and create Barrier and wait for all tasks to complete or should I just create an event/delegate and get the UI to catch this for both UI updates/compeltion
You may checkout Signalr which allows you to achieve PUSH notifications to clients.
Sorry, this answer was assuming Windows Forms, because there was no asp.net tag at first. Hopefully someone will provide a good answer for asp.net as well.
You can use Form.Invoke() to update stuff from the non-GUI thread, here's a simple example:
private void Form1_Load(object sender, EventArgs e)
{
Thread thread = new Thread(DoStuff);
thread.Start();
}
void DoStuff()
{
Thread.Sleep(1000);
this.Invoke(new Action(() => MessageBox.Show("Hey, this was invoked")));
}
With Invoke, you can do just about anything with the Form, it runs the invoked action in the form's thread. So you can change your status text or whatever that way. Of course, you shouldn't have your "business logic" inside the Form class, and you shouldn't use Thread.Sleep, I'm just showing the very basic fact that you can call back to the UI thread this way.
As to whether you should wait for all tasks to complete before doing anything, or show status updates as they execute, that's really up to you. I like to show updates on the UI when possible so the user knows what's going on. It's also good to have a progress bar going if there's something happening that the user might be waiting for. The progress bar can just be a marquee if you don't have a good way to indicate real progress.
I am currently trying to update a chart which is on my form to the background worker using:
bwCharter.RunWorkerAsync(chart1);
Which runs:
private void bcCharter_DoWork(object sender, DoWorkEventArgs e)
{
System.Windows.Forms.DataVisualization.Charting.Chart chart = null;
// Convert e.Argument to chart
//..
// Converted..
chart.Series.Clear();
e.Result=chart;
setChart(c.chart);
}
private void setChart(System.Windows.Forms.DataVisualization.Charting.Chart arg)
{
if (chart1.InvokeRequired)
{
chart1.Invoke(new MethodInvoker(delegate { setChart(arg); }));
return;
}
chart1 = arg;
}
However, at the point of clearing the series, an exception is thrown.
Basically, I want to do a whole lot more processing after clearing the series, which slows the GUI down completely - so wanted this in another thread.
I thought that by passing it as an argument, I should be safe, but apparently not!
Interestingly, the chart is on a tab page. I can run this over and over if the tabpage is in the background, but if I run this, look at the chart, hide it again, and re-run, it throws the exception. Obviously, it throws if the chart is in the foreground as well.
Can anyone suggest what I can do differently?
Thanks!
EDIT:
I know that this can be done in the form thread, as when I assign it back again. However the whole point of using a background worker is to avoid grinding the whole program to a halt. As I said, there is a lot more processing than just this one command.
I assumed that passing it as an argument would allow me to access it in that thread unhindered, but is there a chance that this passed chart still points back to the original chart in some way? If so, how can this be overcome?
I want to block the GUI thread as little as possible - so there seems no point in just invoking every command.
If you want to clear it first, then do a lot of asynchronous work before you redisplay it, why don't you call chart.Series.Clear(); before you invoke the BackgroundWorker? In that case it gets cleared on the main UI thread, then you perform som async work before you again set the chart from the UI thread.
Also, when using a BackgroundWorker, I would use the inbuilt ReportProgress and WorkerCompleted events to avoid the manual cross-thread invoking. That's part of the reason of using the BackgroundWorker in the first place to get this kind of functionality for "free". So setting the chart should be done in the WorkerCompleted to simplify your code (even if that is not the source of the problem in this case).
Check for Invoke Required in bcCharter_DoWork, if yes put the Clear method call in a delegate too.
if (InvokeRequired)
{
Invoke(new MethodInvoker(delegate
{
chart.Series.Clear();
e.Result=chart;
}));
return;
}
I agree with the analysis in the previous posts : you ask a thread to access to a resource of another thread.
Like you used a BackgroundWorker I suggest you to use the Dispatcher :
private void bcCharter_DoWork(object sender, DoWorkEventArgs e)
{
Chart chart = null;
Dispatcher.Invoke(DispatcherPriority.Normal,
new Action(() =>
{
chart.Series.Clear();
}));
}
The problem you are encountering is that you cannot access UI elements on threads other than the one they were created on. However, in your case you can simply clear the chart before calling the background worker.
You can manually marshal UI element access to the correct thread from another thread using Control.Invoke.