We Keep Coding

How to Invoke multiple controls in C#

I have a C# program seems stuck at random time, and after a random while it recovered itself! When it stuck, I can see the memory growth, and when it recover, the memory usage just drops to normal. The CPU usage seems normal all the way and there is no files is written or read (as designed).
The program calls an external (3rd party) DLL function to communicate with hardware, and updates the UI from the DLL's callback which running on a different thread. I have checked the code and found nothing suspicious apart from the following code (redacted):
private void Func(StructType para) {
if (labelA.InvokeRequired) {
labelA.BeginInvoke(new MethodInvoker(() => Func(para)));
return;
}
if (labelB.InvokeRequired) {
labelB.BeginInvoke(new MethodInvoker(() => Func(para)));
return;
}
labelA.Text = para.A;
labelB.Text = para.B;
}
I wonder if this is a proper way of update the UI element from another thread? If not, how to revise it?
In fact, I invoke 6 labels and another form (optionally). It seems working fine for most time but occasionally stuck. I can't post all code here for obvious reason, but just trying to troubleshot from where I doubt most.
Thanks in advance for any suggestions!

You don't need to individually check each each control to determine if you need to invoke it - there is only one UI thread, thus, that check is only useful once. Keep in mind - modifying any UI component is almost certain to cascade into a whole bunch of other reads/writes to other UI components; as a result of that, you have to make the assumption that if you are touching any UI object, you have to assume you're touching all UI components.
With that in mind, I'd recommend you perform your invoke check once, and I recommend performing the check and invoke on the parent control of both labels.
Assuming this refers to the class that is the parent to both those labels, I would modify your code as follows:
private void Func(StructType para) {
if (this.InvokeRequired) {
// Elide the explicit delegate declaration; it's not necessary.
this.BeginInvoke( Func(para) );
// Elide the return statement - multiple returns are messy, and in this case, easily removed.
}
else {
labelA.Text = para.A;
labelB.Text = para.B;
}
}
Be aware that InvokeRequired returns false if the object is disposed, even if the calling thread is not the UI thread.

C# accessing a function from a static class outside the calling thread

BACKGROUND:
I have a class with multiple operations that take more than a couple of seconds to finish. In the meantime I want to update the UI. So normally the BackgroundWorker is the way to go. But for some reason the BackGroundWorker doesn't always work the way I want (example: when I try to use a WebBrowser with events and call the ReportProgress event the BackgroundWorker seemingly crashes).
So I avoid all of this by seperating the Ui from the main thread.
This pseudocode explains it better:
public Ui ui;
main
{
Thread threadUi = new Thread(initiateUi);
//Initiate and start Thread
//Everything I will do from here on will not have any consequences
//on my ui.
//
//Object Ui can still be publicly accessed, making it possible to
//update the user interface.
}
Now when I have an instance of class Bar I would make it accessible for the UI like this:
public Bar bar1;
public Bar bar2;
main
{
//
//other stuff here
//
Thread threadBar1 = //New Thread where I call the Bar initializer function
//and pass bar1 as parameter.
Thread threadBar2 = //idem dito, except with bar2 as parameter
//
//other stuff here
//
}
With this design I can call bar1 and bar2 from my user-interface with the following function:
Program.bar1.someFunction();
PROBLEM:
Now let's say I have a class called FooHandler. This class has a function that searches for all instances of Foo in a certain FooDepository and other functions to manipulate a Foo-object. This is a static class, because in my case, it doesn't need to have multiple instances.
But if I were to call a function from FooHandler, the function runs in my UI-thread, because that is the calling thread (I am not really sure but I couldn't find any documentation about this subject). So there is a good chance I am about to face the problem I started with.
QUESTION:
Is it possible to access the function of a static class without using processing power from the calling thread?

First of all: method scope (where it is defined) has NOTHING to do with program flow. Where method is defined (FooHandler, BarProvider or ThreadX) does not affect where it is called. Actually method is always called in caller's thread.
Because you didn't mention any models, views nor view models and in title says "c#" I'm assuming you talking about WinForms.
In WinForms UI controls needs to be called (updated) from the thread which was used to create them (usually main thread). All the UI controls implement ISynchronizeInvoke interface which is meant to do that. So, instead of regular:
progress.Position = 7;
you need to call Invoke:
progress.Invoke(new Action(() => progress.Position = 7), null)
as there is a lot of boiler-plate code I wrote a little extension function for myself:
public static class ControlExtensions
{
public static void Synchronize(this Control control, Action action)
{
if (control == null || !control.InvokeRequired)
{
action();
}
else
{
control.Invoke(action, null);
}
}
}
So now you can just:
progress.Synchronize(() => progress.Position = 7);
(a little bit less typing and easier to read)
Technically, Invoke on ISynchronizeTarget does not really call given action. It just puts a message (good old WM_xxxx) in message queue (but does this in caller's thread) with delegate as argument. Then, if target (control's) thread is processing messages (in its own thread) it gets this WM_xxxx message, calls the delegate (in callers thread - but this time it is UI thread) and returns.
If you need new Thread to call FooHandler, and you don't want to wait use Tasks (it's probably the easiest way):
Task.Factory.StartNew(() => FooHandler.SearchOrWhatever(...));
it won't wait (won't block the UI thread).
Despite all of this being said, don't assume it's done.
Multi-threading is hard. And all those construct which support save you typing, but the hard part is still there: dead-locks, race conditions, starving, etc.

It is possible by calling this function using another thread. If you use .NET 4 take a look at Task object, which will easily solve the issue. If you function return string for example, then you need Task<string> that will call your function. Then depending on your logic you will either block until it's finished or do something similar. If you are using .NET 4.5 then it's even easier with async/await.

Busy waiting in C#

How do you implement busy waiting in a not total inefficient way? I am facing the issue that I can load the data of my model only in a pull manner, which means I have to invoke getXYZ() methods in a continuous way.
This has to happen not fast enough for user interaction, but fast enought, that when a state in the GUI is changed, the model can be noticed and the new state is received by the getXYZ() methods.
My approach simply be:
while (c.hasChanged()) {
Thread.sleep(500);
}
updateData();
Are there better mechanisms?

Your problem seems to be solvable with Threading.
In WPF you can do:
Thread t = new Thread((ThreadStart)delegate() {
while (true) {
Thread.sleep(500);
if (c.hasChanged())
Dispatcher.Invoke((Action)delegate() {updateData();});
}
}).Start();
In WinForms
Thread t = new Thread((ThreadStart)delegate() {
while (true) {
Thread.sleep(500);
// this must derive from Control
if (c.hasChanged())
this.Invoke((Action)delegate() {updateData();});
}
}).Start();
There may be missing parameters to Invoke (which is needed to execute the code on the calling UI thread) but I'm writing this from my brain so no intellisense at disposal :D
In .NET 4 you can use TaskFactory.StartNew instead of spawning a thread by yourself.
In .Net <= 4, you could use the TreadPool for the thread.
However I recall you need this to be run at once because you expect it to be there checking as soon as possible and the thread pool won't assure you that (it could be already full, but not very likely:-).
Just don't do silly things like spawning more of them in a loop!
And inside the thread you should put a check like
while (!Closing)
so that the thread can finish when you need it without having to resort to bad things like t.Abort();
An when exiting put the Closing to true and do a t.Join() to close the checker thread.
EDIT:
I forgot to say that the Closing should be a bool property or a VOLATILE boolean, not a simple boolean, because you won't be ensured that the thread could ever finish (well it would in case you are closing the application, but it is good practice to make them finish by your will). the volatile keyword is intended to prevent the (pseudo)compiler from applying any optimizations on the code that assume values of variables cannot change

It's not clear from your post exactly what you are trying to do, but it sounds like you should put your model/service calls on a separate thread (via Background worker or async delegate) and use a callback from the model/service call to notify the UI when it's done. Your UI thread can then do busy things, like show a progress bar, but not become unresponsive.

If you are polling from a GUI, use a (WinForms) Timer.
If this is some kind of background process, your Sleep() may be the lesser evil.

Explicit busy waiting is evil and must be avoided whenever possible.
If you cannot avoid it, then build your application using the Observer design pattern and register the interested objects to an object which performs the polling, backed by a thread.
That way you have a clean design, confining the ugly stuff in just one place.

Updating UI after running background work with parallel.Invoke

I'm running heavvy background work with Parallel.Invoke, after all processing has completed I return the method, return again, call a next method to utilize the calculated data I get the error:
Cross-thread operation not valid: Control '' accessed from a thread other than the thread it was created on.
But I already returned from the threads that where created by Parallel.Invoke to the one that called it in the first place. Is it normal that control does not revert to the thread where it started? And how can I assure that this does happen?
Code:
public void TopMethod()
{
Calculate(4);
UpdateGui();
}
public void Calculate(int depth)
{
Recursive(depth);
}
public void Recursive(int depth)
{
if (depth > 0)
System.Threading.Tasks.Parallel.Invoke(
delegate { Recursive(depth - 1); });
}
public void UpdateGui()
{
CalculateOhter(); // Works fine.
controlElement.Focus(); // Causes exception
}
Edits:
I know about Control.Invoke But this would be an ugly solution (don't want to store a delegate in every control) and the program needs to wait for all computations to complete before it can continue. So it would be better if I could somehow force control to return to the thread that I started out with in the first place.

You need to access a control/window from the thread that created that control. Use Control.Invoke and Control.InvokeRequired.

The horrible way to do is to set Control.CheckForIllegalCrossThreadCalls to false. It should get rid of your error, but it is not good design.
The problem with that occurs when a thread other than the creating thread of a control tries to access one of that control's methods or properties, it often leads to unpredictable results.

The example for Control.Invoke involves storing a Delegate, can this be done without storing a delegate for every control? So passing the method I need to call as an argument to the Invoke call (tried this but cannot get it to work).
The program needs to wait for all computations to complete before it can continue so it would be better if I could somehow force control to return to the thread that I started out with in the first place.
I don't understand why this does not happen at default, why does it not just return to the thread it started with when everything is complete?

Solved it, turns out I created a seperate thread to call the given code in the first place, kinda stupid :P

C#, WPF, Automatically call Dispatcher.Invoke when needed?

I have a program with a Geospace map embedded into it. The event handling for the map is handled on a separate thread to keep the map responsive (for example, the events that fire when the map is clicked).
The problem I am having is when the map fires an event, my program needs to update some things in it's gui, and also call back into the map to handle placing pictures on the map.
I tried wrapping the entire event handler method in this.Dispatcher.Invoke, which puts me back on the main UI thread. This works great for updating my GUI, but when i call back into the map, I'm still on the UI thread which can cause some problems in the map.
Basically, in order to make this work, I'm going to have to run dispatcher.invoke each time I want to change a control on my gui. Is there a way I can automatically do this without wrapping each call in dispatcher.invoke? I hope this all makes sense.
Heres some example code for the event I'm talking about..
private void Map_OnMapClicked(object sender, MapClickedEventArgs e)
{
this.Dispatcher.Invoke(DispatcherPriority.Normal, (Action)(() =>
{
// Do something to update my gui
}));
Map.DoSomethingInTheMap();
this.Dispatcher.Invoke(DispatcherPriority.Normal, (Action)(() =>
{
// Do something to update my gui
}));
//etc etc etc
}

If you need to keep each respective operation in its own synchronization context, this is unfortunately the best approach. You'll need to Invoke using the Dispatcher whenever you update your GUI.
Here are a couple of suggestions for making this easier:
Try to batch your GUI operations. In addition to requiring less code (via less invoke calls), you'll get better performance. Each Dispatcher.Invoke call carries a fair amount of overhead, since it posts a message into the Dispatcher's message queue which must be processed.
Consider using Dispatcher.BeginInvoke to avoid blocking, unless you really need to wait.
If you can use the Task Parallel Library from .NET 4 (or the backport to 3.5sp1 in the Rx Framework), you might want to consider reworking this to use Task instances synchronized to the GUI thread. By creating a TaskScheduler using FromCurrentSynchronizationContext, you can schedule tasks to run on the GUI easier than the Dispatcher Invoke calls. This also can give you some control over batching, since you can schedule them, and block/wait as needed, very easily.

You could use something like PostSharp or try to condense your UI updates to single method calls where you invoke once and do a lot. Or even a pattern like this (it's Winforms but the idea is the same):
private void UpdateToolStripItemText(ToolStripItem toolStripItem, string text)
{
if (InvokeRequired)
{
Invoke(new UpdateToolStripItemTextDelegate(UpdateToolStripItemText), new object[] { toolStripItem, text });
}
else
{
if (text != null)
{
toolStripItem.Text = text;
}
}
}