Develop Reference

c# Multi threading operation triggered by a form

Good day,
After being unsuccessful in my Google & Stackoverflow queries (not sure what I should search for), I'm posting here a public question.
I have a main form (frmMainMenu). Whenever this form is loaded and a button on this form is pressed, I'm trying to update a chart. However, as this could be CPU-demanding, I was considering calling the operation to retrieve the chart from another thread.
I'm constantly getting an error : Cross-thread operation not valid: Control 'labelX2' accessed from a thread other than the thread it was created on. System.Windows.Forms at System.Windows.Forms.Control.get_Handle()
The idea behind is also to display this symbol (referenced as the circularProgress1 control whenever data is being retrieved and to hide it whenever the operation is complete.
Here below is the code of my method in the userform :
[...]
private void feedDashboard()
{
Thread l_Thread;
ClsStartPgm l_Start = null;
try
{
this.Invoke(new MethodInvoker(delegate()
{
l_Thread = new Thread(() =>
{
try
{
l_Start = new ClsStartPgm();
l_Start.getDashboardInformations(
this.labelX2,
this.circularProgress1,
this.tmr_Progress,
this.chart1,
this.expandablePanel_1);
}
finally
{
// onCompleted();
}
});
l_Thread.Start();
}));
}
catch (Exception exc)
{
ClsFinappErrorManager.manageException(exc);
}
finally
{
}
}
[...]
and if it can be helpful, here is my mentioned getDashboardInformations method of my Class ClsStartPgm
public sealed class ClsStartPgm
{
[...]
// (Constructors, accessors and other methods not mentioned here
// to simplify the reading of my question)
[...]
public void getDashboardInformations(
LabelX pInformationText,
Controls.CircularProgress pCircularProgress,
System.Windows.Forms.Timer pTimer,
Chart pChart1,
ExpandablePanel pExpandablePanel1)
{
List<double> l_DoubleList = null;
List<string> l_StringList = null;
try
{
pTimer.Start();
this.m_Busy_Dashboard_Generation = true;
this.m_Busy_Dashboard_Generation = false;
double[] yValues = l_DoubleList.ToArray();
string[] xValues = l_StringList.ToArray();
pChart1.Series["MySerie"].Points.Clear();
// Populate series data
pChart1.Series["MySerie"].Points.DataBindXY(xValues, yValues);
// Set Doughnut chart type
pChart1.Series["MySerie"].ChartType = SeriesChartType.Pie;
// Set title of the expendable panel
pExpandablePanel1.TitleText = "Situation: " + DateTime.Now.ToShortDateString();
[...]
}
catch (Exception exc)
{
ClsFinappErrorManager.manageException(exc);
}
finally
{
l_Tuple = null;
l_Accounts = null;
}
}
}
Please, could anyone guide me on what's wrong in my code? I'm definitely not asking to get the code written for me. However, I would be keen on understanding what I'm doing incorrectly here in my approach.
Many thanks for your appreciated help and best wishes,

Why am I allowed to load an image in the non-GUI thread?

Well known is that you cannot change the GUI with any other thread than the GUI thread. So a simple trick that is commonly used (which I use) is invoking:
this.Invoke((MethodInvoker)delegate { pictureBox1.Visible = false; });
I was building my program and started it, quickly noticing that I forgot to put an PictureBox.Load(string url) in the invoker, however no error had occurred.
So I am curious, why am I not allowed to do (in non-GUI thread):
pictureBox1.Visible = false; // eg.
But am allowed to do:
pictureBox1.Load(url); // url = link to image

When you load a new image, this is what happens inside the PictureBox (this is called from the Load method):
private void InstallNewImage(Image value,
ImageInstallationType installationType)
{
StopAnimate();
this.image = value;
LayoutTransaction.DoLayoutIf(AutoSize, this, this, PropertyNames.Image);
Animate();
if (installationType != ImageInstallationType.ErrorOrInitial)
{
AdjustSize();
}
this.imageInstallationType = installationType;
Invalidate();
CommonProperties.xClearPreferredSizeCache(this);
}
So you can see that all it really does is set the image and then call Invalidate, which can be called from other threads.
Visible (inherited from Control), which you can see here, does a lot of stuff through p/invoke and must be done on the main UI thread.
protected virtual void SetVisibleCore(bool value) {
try {
System.Internal.HandleCollector.SuspendCollect();
if (GetVisibleCore() != value) {
if (!value) {
SelectNextIfFocused();
}
bool fireChange = false;
if (GetTopLevel()) {
// The processing of WmShowWindow will set the visibility
// bit and call CreateControl()
//
if (IsHandleCreated || value) {
SafeNativeMethods.ShowWindow(new HandleRef(this, Handle), value ? ShowParams : NativeMethods.SW_HIDE);
}
}
else if (IsHandleCreated || value && parent != null && parent.Created) {
// We want to mark the control as visible so that CreateControl
// knows that we are going to be displayed... however in case
// an exception is thrown, we need to back the change out.
//
SetState(STATE_VISIBLE, value);
fireChange = true;
try {
if (value) CreateControl();
SafeNativeMethods.SetWindowPos(new HandleRef(window, Handle),
NativeMethods.NullHandleRef,
0, 0, 0, 0,
NativeMethods.SWP_NOSIZE
| NativeMethods.SWP_NOMOVE
| NativeMethods.SWP_NOZORDER
| NativeMethods.SWP_NOACTIVATE
| (value ? NativeMethods.SWP_SHOWWINDOW : NativeMethods.SWP_HIDEWINDOW));
}
catch {
SetState(STATE_VISIBLE, !value);
throw;
}
}
if (GetVisibleCore() != value) {
SetState(STATE_VISIBLE, value);
fireChange = true;
}
if (fireChange) {
// We do not do this in the OnPropertyChanged event for visible
// Lots of things could cause us to become visible, including a
// parent window. We do not want to indescriminiately layout
// due to this, but we do want to layout if the user changed
// our visibility.
//
using (new LayoutTransaction(parent, this, PropertyNames.Visible)) {
OnVisibleChanged(EventArgs.Empty);
}
}
UpdateRoot();
}
else { // value of Visible property not changed, but raw bit may have
if (!GetState(STATE_VISIBLE) && !value && IsHandleCreated) {
// PERF - setting Visible=false twice can get us into this else block
// which makes us process WM_WINDOWPOS* messages - make sure we've already
// visible=false - if not, make it so.
if (!SafeNativeMethods.IsWindowVisible(new HandleRef(this,this.Handle))) {
// we're already invisible - bail.
return;
}
}
SetState(STATE_VISIBLE, value);
// If the handle is already created, we need to update the window style.
// This situation occurs when the parent control is not currently visible,
// but the child control has already been created.
//
if (IsHandleCreated) {
SafeNativeMethods.SetWindowPos(
new HandleRef(window, Handle), NativeMethods.NullHandleRef, 0, 0, 0, 0, NativeMethods.SWP_NOSIZE |
NativeMethods.SWP_NOMOVE | NativeMethods.SWP_NOZORDER | NativeMethods.SWP_NOACTIVATE |
(value ? NativeMethods.SWP_SHOWWINDOW : NativeMethods.SWP_HIDEWINDOW));
}
}
}
finally {
System.Internal.HandleCollector.ResumeCollect();
}
}
Just as a side-note, a lot of these "what happens under the hood" can be figured out by browsing the reference source, or creating a small application and decompiling it (I would recommend JetBrains DotPeek, or ildasm works too).

The reason you do not get the "Cross-thread operation not valid" message is because the exception is thrown when the control Handle property is accessed:
public IntPtr Handle {
get {
if (checkForIllegalCrossThreadCalls &&
!inCrossThreadSafeCall &&
InvokeRequired) {
throw new InvalidOperationException(SR.GetString(SR.IllegalCrossThreadCall,
Name));
}
if (!IsHandleCreated)
{
CreateHandle();
}
return HandleInternal;
}
}
As you can see from the accepted answer, SetVisibleCore (called by Visible) uses Handle several times, but InstallNewImage (used by Load) does not. (Actually, Invalidate does access the Handle property, but it does so within a thread safe call scope which is fine.)

ManagementObjectSearcher causes re-entrancy issues for onclick handler

I am having an odd problem with protecting a section of code. My application is a tray app. I create a NotifyIcon inside my class (ApplicationContext). I have assigned a balloon click handler and a double click handler to the NotifyIcon object. there is also a context menu but I am not showing all code. Only important pieces.
public class SysTrayApplicationContext: ApplicationContext
{
private NotifyIcon notifyIcon;
private MainForm afDashBoardForm;
public SysTrayApplicationContext()
{
this.notifyIcon = new NotifyIcon();
this.notifyIcon.BalloonTipClicked += notifyIcon_BalloonTipClicked;
this.notifyIcon.MouseDoubleClick += notifyIcon_MouseDoubleClick;
// ... more code
}
Both handlers launch or create/show my form:
private void notifyIcon_MouseDoubleClick(object sender, MouseEventArgs e)
{
if (e.Button == MouseButtons.Left)
{
openDashboard();
}
}
private void notifyIcon_BalloonTipClicked(object sender, EventArgs e)
{
openDashboard();
}
private void openDashboard()
{
if (dashBoardForm != null)
{
log.Debug("Dashboard form created already, so Activate it");
dashBoardForm.Activate();
}
else
{
log.Debug("Dashboard form does not exist, create it");
dashBoardForm = new MainForm();
dashBoardForm.Show();
}
}
There is a problem with the above code. Maybe more than 1. Issue: it is possible to display 2 dashboard forms which is not what I want. If user double clicks on tray icon while balloon message is displaying causes a race condition in openDashboard. I can reproduce this easily. So I added a lock around the code in openDashboard code and, to my surprise, that did NOT prevent 2 dashboard forms from displaying. I should not be able to create 2 MainForms. Where am I going wrong here?
here is the updated code with lock statement:
private void openDashboard()
{
lock (dashBoardFormlocker)
{
if (dashBoardForm != null)
{
log.Debug("Dashboard form created already, so Activate it");
dashBoardForm.Activate();
}
else
{
log.Debug("Dashboard form does not exist, create it");
dashBoardForm = new MainForm();
dashBoardForm.Show();
}
}
}
Note: lock object was added to the class and initialized in constructor.
private object dashBoardFormlocker;
UPDATE: Showing more code. this is how code gets started :
static void Main()
{
if (SingleInstance.Start())
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
XmlConfigurator.Configure();
// For a system tray application we don't want to create
// a form, we instead create a new ApplicationContext. The Run method takes
Application.Run(new SysTrayApplicationContext());
SingleInstance.Stop();
SingleInstance.Dispose();
}
}
}
UPDATE 2: Provide more code for clarity
public partial class MainForm : Form
{
public MainForm()
{
log.Trace("MainForm constructor...");
InitializeComponent();
// ... code not shown
this.label_OSVersion.Text = getOSFriendlyName();
// .. more code
}
private string getOSFriendlyName()
{
try
{
string result = string.Empty;
var mgmtObj = (from x in new ManagementObjectSearcher("SELECT Caption FROM Win32_OperatingSystem").Get().OfType<ManagementObject>()
select x.GetPropertyValue("Caption")).FirstOrDefault();
result = mgmtObj != null ? mgmtObj.ToString() : string.Empty;
OperatingSystem os = Environment.OSVersion;
String sp = os.ServicePack ?? string.Empty;
return !string.IsNullOrWhiteSpace(result) ? result + sp : "Unknown";
}
catch (System.Exception ex)
{
log.Error("Error trying to get the OS version", ex);
return "Unknown";
}
}
}

The main UI thread must always pump a message loop to support communication from COM components.
So when you do a blocking operation from the UI thread like locking or joining a thread, (EDIT: edited based on Peter Duniho's fix) the UI thread will enter an 'alertable' state, allowing COM to dispatch certain type of messages, which in turn can cause re-entrancy issues like in your scenario.
Look at the answer to this question (Why did entering a lock on a UI thread trigger an OnPaint event?) for a much more accurate explanation.
Looking at the source code of ManagementObjectSearcher.Get there is a lock (inside Initialize), and since you call it from the constructor of your form, it may lead to the second event triggering while the form's constructor has not finished. The assignment to the dashBoardFormlocker variable only happens after the constructor finishes, so that would explain why it was null on the second entry.
The moral of the story is never do blocking operations on the UI thread.

Without a good, minimal, complete code example that reliably reproduces the problem, it's impossible to know for sure what the problem is. But the guess by answerer tzachs seems reasonable. If so, you can fix your problem by changing your method to look like this:
private bool _dashboardOpen;
private void openDashboard()
{
if (_dashboardOpen)
{
if (dashBoardForm != null)
{
log.Debug("Dashboard form created already, so Activate it");
dashBoardForm.Activate();
}
}
else
{
log.Debug("Dashboard form does not exist, create it");
_dashboardOpen = true;
dashBoardForm = new MainForm();
dashBoardForm.Show();
}
}
In that way, any re-entrant attempt to open the window will be detected. Note that you still need the check for null before actually activating; you can't activate a window that hasn't actually finished being created yet. The subsequent call to Show() will take care of activation anyway, so ignoring the activation in the re-entrant case shouldn't matter.

Disposed Forms with a Base and threading returns null for progress bar

I have a base form that I use when calling 2 forms. Previously when calling the forms I didn't dispose of them, but I have found that reusing them, they would stay in memory and not get collected. So I have instead used a using statement instead to clear the memory, and all my problem are fixed.
But now a new problem arises, one that I had previously when testing my app with mono on Linux. I though it might be a mono specific problem, but since adding the using statement the same thing happens on my Windows machine. So it might just be that the Garbage Collector on Mono is different and was disposing properly of my forms.
Here is my problem I have a thread that I start to extract files in the background And I have progress bar telling me the progress, before using the dispose if I closed the form and reopened it my files extracted correctly and the progress bar was working fine. But now they work fine the first time, but if I reopen the form or the other one that has the same base, the extraction is not working, no files are extracted because I have a null exception when reporting the progress.
private void ExtractFiles()
{
Zip.ExtractProgress += new EventHandler<ExtractProgressArgs>(Utils_ExtractProgress);
Thread t = new Thread(new ThreadStart(Zip.ExtractZip));
t.IsBackground = true;
t.Start();
FilesExtracted = true;
}
void Utils_ExtractProgress(object sender, ExtractProgressArgs e)
{
UpdateProgress(e.Pourcentage);
}
private delegate void UpdateProgressDelegate(int Pourc);
private void UpdateProgress(int Pourc)
{
lock (this)
{
if (Progress.ProgressBar.InvokeRequired)
{
UpdateProgressDelegate del = new UpdateProgressDelegate(UpdateProgress);
Progress.ProgressBar.BeginInvoke(del, Pourc);
} else
{
Progress.Value = Pourc;
}
}
}
This code is in my BaseForm, the Progress control isn't null, but all of it's properties have null exceptions. So when checking if Invoked is required it raises an Null exception.
Here is my Zip.Extract method
public static event EventHandler<ExtractProgressArgs> ExtractProgress;
static ExtractProgressArgs Progress;
internal static void ExtractZip()
{
try
{
using (ZipFile zip = ZipFile.Read(Variables.Filename))
{
Progress = new ExtractProgressArgs();
Progress.TotalToTransfer = Convert.ToInt32(zip.Sum(e => e.UncompressedSize));
zip.ExtractProgress += new EventHandler<ExtractProgressEventArgs>(zip_ExtractProgress);
Old = 0; New = 0;
foreach (ZipEntry item in zip)
{
item.Extract(Variables.TempFolder, ExtractExistingFileAction.OverwriteSilently);
}
}
} catch (Exception)
{
}
}
static long Old;
static long New;
static void zip_ExtractProgress(object sender, ExtractProgressEventArgs e)
{
if (e.EventType == ZipProgressEventType.Extracting_EntryBytesWritten)
{
New = e.BytesTransferred;
Progress.Transferred += New - Old;
Old = e.BytesTransferred;
if (ExtractProgress != null)
{
ExtractProgress(e.CurrentEntry, Progress);
}
} else if (e.EventType == ZipProgressEventType.Extracting_AfterExtractEntry)
{
Old = 0;
}
}
Might be because my Zip.Extract is static? I have almost no knowledge of multi-threading, like synchronization, etc.

The short answer is yes, some of your problems are due to the static nature of those operations.
You should be able to resolve the problem by removing the static declarations from your Zip class and then creating an instance of it as needed.

Stop a loop inside a method in C#

Is there any way to stop a running loop inside another method or insert a break statement dynamically in C#?
Thanks
Edit : I want to be able to dynamically intercept the method and insert a break to stop the loop when an event gets triggered in another function.I have several instances of the class and I want to stop the loop in each instance whenever required and manage all the instances. Consider multiple instances to be in a generic list
Example :
List<myclass> objlist=new List<myclass>();
foreach(myclass obj in objlist)
{
obj.loopingfunction().BreakLoop //or something like this (assuming that the loopingfunction is already called)
}
I need this because I want to break the loop once the user stores some huge amount of data.When the user imports the data,I get a event fired. But I cannot keep checking the database from multiple instances since it screws up sqlserver.
This is in an ASP.Net application.

If the whole thing is running in a single thread, it wouldn't make any sense. If the loop is running, then nothing else is running at the same time. If you're running a loop on another thread and the controlling method on another thread, you can either abort the loop thread completely or check a flag inside the loop to decide whether or not you should break and set the flag appropriately in the controlling method.
Update: make that function return a boolean value indicating whether you should break and use it in an "if" statement:
if (myFunctionShouldBreakLoop()) break;

Another option would be to raise a CancelEventArgs during every iteration of the loop. Probably not the most efficient, but another option nonetheless:
private void SomeMethod()
{
for (int i = 0; i <= 100000; i++)
{
Console.WriteLine(i);
if (LoopIncrement != null)
{
CancelEventArgs args = new CancelEventArgs();
LoopIncrement(null, args);
if (args.Cancel)
{
break;
}
}
}
And then elsewhere:
myObj.LoopIncrement += MyHandler;
private void MyHandler(object sender, CancelEventArgs e)
{
if(someCondition)
{
e.Cancel = true;
}
}
This way you can somewhat control the loop from outside....

Have the condition in a locked property.
private Boolean BreakCondition
{
get { lock(_LockObject) { return _BreakCondition; } }
set { lock(_LockObject) { _BreakCondition = value; } }
}
private Boolean _BreakCondition = false;
private Object _LockObject = new Object();
if (this.BreakCondition)
{
break;
}

How about using iterators, and yield magic to solve the problem.
Here is an article on infinite lists that might be useful
http://www.codethinked.com/post/2009/02/04/Infinite-Lists-With-C-Yield.aspx
class Program
{
static void Main(string[] args)
{
Predicate<int> when = i => i > 100 && Console.ReadKey().KeyChar.ToString() == "0";
foreach(var i in Numbers().BreakOn(when))
{
Console.WriteLine(i);
}
Console.ReadLine();
}
private static IEnumerable<int> Numbers()
{
var i = 0;
while(true)
{
yield return i++;
}
}
}
public static class Util
{
public static IEnumerable<int> BreakOn(this IEnumerable<int> sequence, Predicate<int> when)
{
foreach(int i in sequence)
{
if(when(i))
{
yield break;
}
yield return i;
}
}
}

I think you can use flag
bool stop = false;
for(int i=0;i<num;i++)
{
if(stop) break;
}

The short answer is: no. If you don't control the code, then you can't cause the loop to terminate.
If you do control the code, you could build in some sort of cooperation, but it sounds messy. Maybe you can elaborate on why?