Develop Reference

Invoke not switching back to separate thread

I have the method below that is running on a separate thread from the main UI thread, and I am trying to update the ListBox control on the main thread. The code does work and the field does get updated, but when the Invoke method runs it switches to the main thread. The problem is that the code after the Invoke also runs on the main thread, but I need it to run on the separate thread.
public static void Status_Message(string str, int destination, int prompt)
{
//Clear_System_Message_Area();
sysmsg++;
ListBox tl = Application.OpenForms["GMLEC"].Controls["groupBox2"].Controls["TestList"] as ListBox;
if (!tl.InvokeRequired)
{
tl.Items.Add(str);
tl.Refresh();
}
else
{
tl.Invoke(new Action<string, int, int>(Status_Message), str, destination, prompt);
}
if (destination == 1)
{
Printer.Output(str);
}
if (prompt == 1)
{
Pause(false);
}
if (sysmsg > 23)
{
Pause(true);
}
}
Is there a way to make it go back to the separate thread?

If you don't want code run on the UI thread, don't invoke the method that contains it.
For what it's worth, I disagree with any code that uses InvokeRequired. First of all, you ought to know from the context whether invoke is required or not. If you don't know which thread the code that's executing is on, then there is too much coupling between the UI and background task parts of the code.
But secondly, the Control.Invoke() method has to check which thread is current anyway, because it has to work whether you are on the UI thread or not. You can always call it safely from the UI thread, and when you do, it can't go queueing up your delegate for invocation and then waiting for it, because that would deadlock. It has to just invoke the delegate directly, but only in that case, which means it's doing the InvokeRequired check anyway.
So, taking all of that into account, just write your code to always invoke the part that needs invoking, and be done with it.
For example:
public static void Status_Message(string str, int destination, int prompt)
{
//Clear_System_Message_Area();
sysmsg++;
ListBox tl = Application.OpenForms["GMLEC"].Controls["groupBox2"].Controls["TestList"] as ListBox;
tl.Invoke((MethodInvoker)(() =>
{
tl.Items.Add(str);
tl.Refresh();
}));
if (destination == 1)
{
Printer.Output(str);
}
if (prompt == 1)
{
Pause(false);
}
if (sysmsg > 23)
{
Pause(true);
}
}
Now, some other notes about this:
It's doubtful that you should be calling Refresh(). Let Winforms deal with updating on its own. If you've somehow interfered with it refreshing the window normally, fix that. Don't hack around it by calling Refresh() yourself.
It's almost certain that there's a better way to encapsulate the ListBox object than by always looking it up from the top of the UI control graph. For example, maybe the actual object should have been referenced directly (e.g. from a TestList field) and passed to the code that will eventually need it.
Finally, and most important, the fact that you're using Invoke() at all is a big warning flag in modern code. There's a decent chance that your overall code could be refactored to use async/await in a way that allows it to read more naturally and still work correctly, but at the very least it would be better to use Progress<T> to mediate cross-thread updates like this.
To address any of these issues would be beyond the scope of the current question, but I do encourage you to take the suggestions under consideration.

This might help...
normally I use Invoke() to activate a part of the script after a certain time. Invoke() Does NOT repeat, if you want it to repeat you can use InvokeRepeating().
another option is to use "Multi-Threading". Here's how to use Multi-Threading:
using System.Threading
public static Thread newThread = new Thread(MultiThread)
private void Start()
{
newThread.Start()
//also newThread.Abort() to quit the thread
}
private static void MultiThread()
{
// this is the seporate thread
// i normally use this for a "while (True)" loop cause it will stop responding
//otherwise
}
srry for any typos
Hopefully this helps

How do i pass data from Thread to UI-Thread and view that data?

I really don't know how to properly get data from a Thread.
In a thread (or Task, doesnt matter) i want to calculate a lot of doubles. When this is finished i want to show this data in a grid and in a graphic-chart. So i tried to return some type of
Observable<List<double>>
When i then wanted to create a "new ViewModel(data)", i get exceptions cause of threads.
So how do i properly get such a list back from a thread and use it in UI?
Or maybe pass this data while calculating to show some live values would also be nice..
thanks for answers, just need a few tips

This kind of functionality is common and is often accomplished using the BackgroundWorker Class. There is a code example on the linked page and you can find another with feedback in my answer to the How to correctly implement a BackgroundWorker with ProgressBar updates? question on this website.
Alternatively, you can use the Dispatcher object from the UI thread to pass values to that thread. Note that each thread has it's own Dispatcher, so be sure to call the one from the UI thread. You can use this little helper method:
public object RunOnUiThread(Delegate method)
{
return Dispatcher.Invoke(DispatcherPriority.Normal, method);
}
You can use it like this:
RunOnUiThread((Action)delegate
{
// You can run any number of lines of code on the UI Thread here
});
Or inline, like this:
RunOnUiThread((Action)delegate { UpdateData(); });
I have this method in a separate class that has constructors like this:
private UiThreadManager(Dispatcher dispatcher)
{
Dispatcher = dispatcher;
}
public UiThreadManager() : this(Dispatcher.CurrentDispatcher) { }
I call this constructor on the UI thread to ensure that the Dispatcher that I will be using is in fact the Dispatcher from the UI thread.

How to let the code wait to be executed until the other event handler finished?

In the following code, I want to use the geometryService (a utility class provided by third party) to sequentially calculate several shape area. I failed because the second time area calculation mustn't wait until the first calculation is finished. To resolve this issue, I can put the second area calculation into the finish calculation event handler, but the code is a mess. Is there a better way I can make geometryService.AreasAndLengthsAsync(secondShape) wait to execute untilgeometryService.AreasAndLengthsAsync(firstShape) is finished executing?
Shape firstShape = new Shape();
Shape secondShape = new Shape();
GeometryService geometryService = new GeometryService();
geometryService.AreaAndLengthsCompleted += GeometryService_AreasAndLengthsCompleted;
geometryService.AreasAndLengthsAsync(firstShape);
geometryService.AreasAndLengthsAsync(secondShape);
private void GeometryService_AreasAndLengthsCompleted(object sender, AreasAndLengthsEventArgs args){ }

You could place each Shape in a Queue<Shape>
Then kick off the first calculation, and in the completed handler check the queue for any other Shapes and if there is one, process it.
Additionally, the method you are calling is AreasAndLengthsAsync(). By convertion most API designers will include synchronous alternatives named the same byt without the Async part.. so look for AreasAndLengths() as an alternative.

This is a classic problem with async methods. If you're using the new MS Async CTP, you can encapsulate some of this stuff fairly cleanly, but if you're stuck using the traditional stuff, it's difficult to get clean code out of this.
One of the approaches that I take is to wrap the event-handler pattern with a continuation-passing pattern. It's not perfectly clean, but I like the look of the resulting code better. So you could do something like this:
public static void GetAreasAndLengthsAsync(Shape shape, Action<SomeResult> callback)
{
var geometryService = new GeometryService();
geometryService.AreasAndLengthsCompleted += (s, e) =>
{
if (callback != null)
{
callback(e.SomeResult);
}
};
geometryService.AreasAndLengthsAsync(shape);
}
And you can then use it like this:
GetAreasAndLengthsAsync(firstShape, firstShapeResult =>
{
GetAreasAndLengthsAsync(secondShape, secondShapeResult =>
{
DoSomethingWithTheseResults(firstShapeResult, secondShapeResult);
});
});
Something like that, at any rate. The formatting is kinda ugly, but at least it expressed your intent fairly well. (Haven't compiled the code, there may be errors.)
If you don't like recreating the geometryService each time, you can do that at the field level in your class, and then pass the callback method as part the UserState parameter that most Async methods include.

You can use AutoResetEvent or ManualResetEvent, simply define one at the top of your class, and call Wait in the event that you want to wait for the other event, and then call Set in the event that you your waiting for, Wait will block until Set is called.
http://msdn.microsoft.com/en-us/library/system.threading.autoresetevent.aspx
http://msdn.microsoft.com/en-us/library/system.threading.manualresetevent.aspx
I would like to add that this is not ideal, but it you must have Serialized events and you are relying on a third party API than this may be the only option.

InvokeRequired is true on PictureBox. How to deal with this?

I had another question on my PictureBox calls giving me 3 kinds of errors, some great answers came in particularly from Conrad Frix. So it led me to figure out where my problem is, but now to fix it I am not 100% sure on.
Basically I have a Windows Form timer that is checking for some event to be true, if it is, then it tells the system to send some data out 2 seconds after said event (a value ) is past some threshold.
I think all the timers I have is creating a nasty race condition with my PictureBox that I use in several places to get the image from:
new Bitmap(myPicBox.Image);
etc...
I read somewhere that the interval on the timer should be at least 50. Set that from 33. I found out I can do a picCapture.InvokeRequired to see if its going to basically die. I know I need to use a delegate but only ever used those to set something... not to get an image from.... not sure how to set that up... I know what is indeed causing it, it is this combination of code:
private void timer1_Tick(object sender, EventArgs e)
{
if(someCOnditionTrue)
{
TimerCallback tc = new TimerCallback(sendDataFast); //only
//doing all this so i can have the method run two seconds after
// the condition is detected to be true.
System.Threading.Timer t = new System.Threading.Timer(tc, null, 2000, Timeout.Infinite);
}
}
void sendDataFast(Object stateObject)
{
//using this so the execution is not haulted while the sending of data takes place.
EmergencyDelegate delEmergency =
new EmergencyDelegate(mic.sendEmergencyData);
Image imgclone;
if (picCapture.InvokeRequired)
{
Console.WriteLine("HFS Batman! its going to die ");
}
lock (lockObject2) //i admit no clue what im doing here and doesn't seem to help.
{
Image img = picCapture.Image;
imgclone = (Image)img.Clone();
}
delEmergency.BeginInvoke(imgclone, null, null); //deep in the call to
//sendEmergencyData i get the **ParameterNotValid** almost everytime.
imgclone.Dispose(); //to free memory?
}
As per my previous question, no longer seem to get the memory issues or other errors in the timer1_tick event... (out of memory error was one).
I think the biggest issue is how can I handle the picCapture.InvokeRequired when I need its image data? I am certain its the threading timer call inside the timer1_click I do that is causing this....

As its name suggests, InvokeRequired means you need to call Invoke (or BeginInvoke) when accessing the control.
Note that this is Control.Invoke/Control.BeginInvoke, not the Invoke/BeginInvoke which are present in delegates... although you'll need a delegate in order to call Invoke/BeginInvoke, just to add more confusion to the mix.
See the Windows Forms section of my threading tutorial for more details. The overall tutorial could do with updating, but I believe this bit is okay. In other situations you may also want to consider using BackgroundWorker, but I don't think that's likely to be relevant for you in this particular case.

I think that you have got a wrong understanding about InvokeRequired. InvokeRequired indicates that the current thread is not the same as the UI thread and it will not be safe to access the control state now. If such is the case then you have to use Control.Invoke to marshal call to the UI thread and then access the control state. Read here on MSDN for more info.
In your case, unless the PictureBox image is changing, I would suggest that you rather make a clone of the image upfront and use that. Otherwise you need to use Control.Invoke.

You've got too many threads going to bring this to a good end. Both the Timer and the delegate's BeginInvoke() method will use a threadpool thread. The problem is that the PictureBox.Image property is only partially thread-safe. It can be accessed by only one thread at a time. Your code will die with an exception when the image is painted by the UI thread at the exact same time your code is calling the Clone() method.
Your lock statement doesn't solve the problem, the PictureBox is accessing the Image property without using that same lock. I would strongly recommend getting rid of the threading first, use a System.Windows.Forms.Timer instead of a System.Threading.Timer. It's Tick event is raised on the UI thread. That will however make the UI thread unresponsive while the event is running, it depends how long it takes whether that's noticeable to the user. More than, say, 100 milliseconds gets to be a problem.
The only other approach is to try to make the PictureBox control thread-safe. That's possible to some degree. Add a new class to your project and paste the code shown below. Compile. Drop the new control from the top of the toolbox onto your form, replacing the existing PB. Beware that this is only a partial solution, displaying an animated GIF or using the ImageLocation property will still bomb. Use the provided Clone method instead of calling Clone on the Image property.
using System;
using System.Drawing;
using System.Windows.Forms;
class MyPictureBox : PictureBox {
private object locker = new object();
public new Image Image {
get { return base.Image; }
set { lock (locker) { base.Image = value; } }
}
public Image Clone() {
lock (locker) {
return (this.Image != null) ? (Image)this.Image.Clone() : null;
}
}
protected override void OnPaint(PaintEventArgs pe) {
lock (locker) {
base.OnPaint(pe);
}
}
}

C# Func Delegate throws Thread Exception

So, maybe I misunderstood the usage of Func but
Func<ComboBox, string> getCurrentValue = s => s.SelectedValue.ToString();
Creates a Thread Error when calling getCurrentValue(cb_message_type) from my Workerthread.
Whats the best solution to get the Selected Value of the Combobox?
Many thanks,
rAyt
Edit
MSDN
"The underlying type of a lambda expression is one of the generic Func delegates. This makes it possible to pass a lambda expression as a parameter without explicitly assigning it to a delegate."

Since windows controls have thread affinity, you have 2 options:
query this data before doing your threading code, for example passing it in as the state to the worker
query it in the worker via Control.Invoke
Since the first is trivial, I'll give an example of the second using captured variables:
object value = null;
yourCombo.Invoke((MethodInvoker) delegate {value=yourCombo.SelectedValue;});
string s = value.ToString();
Here the bits inside delegate {...} happen on the UI thread, even if the code around it is on the worker thread. You can mix the above either inside your func, or call the entire func once you've switched threads.

You need to call Control.Invoke with that delegate - or make the delegate itself call it.
Using a lambda expression doesn't change the threading requirements of Windows Forms - it just makes it easier to create a delegate.
You might want to make a convenience method to do this:
// (Untested)
public static Func<TControl, TResult> WrapInvocation(Func<TControl,TResult> func)
where TControl : Control
{
return control => {
return (TResult) control.Invoke(func);
};
}
Use as:
Func<ComboBox, string> getCurrentValue = s => s.SelectedValue.ToString();
getCurrentValue = WrapInvocation(getCurrentValue);
Then you can call getCurrentValue(comboBox) from any thread.

The problem is that UI controls can only be used on the UI thread,
You need to call the Invoke method within the other thread, like this:
Func<ComboBox, string> getCurrentValue =
s => s.Invoke(new Func<object>(() => s.SelectedValue)).ToString();
The Invoke method takes a delegate and executes it on the UI thread.

Generally speaking, you cannot access UI controls from a thread other than that they were created on. To overcome that, you'll either have to check ISynchronizeInvoke.InvokeRequired on the control in question and branch, invoke a delegate, etc. or use a SynchronizationContext. First option is very cumbersome, whereas second one is pretty elegant:
var synchronizationContext = WindowsFormsSynchronizationContext.Current;
string currentValue = "";
synchronizationContext.Send(
() => currentValue = getCurrentValue(comboBox),
null);

If the thread will simply be reading the ComboBox, the best option if practical is probably to have an event handler on the thread which grabs the ComboBox value any time it changes, and then exposes that value via property which can be read from any thread.