We Keep Coding

Canceling delegates on form close (C#)

A quick question about concurrency in C#.
I have in my code the following method to update a textbox:
public void diag(string text)
{
if (InvokeRequired)
{
Invoke(new Action<string>(diag), text);
}
else
{
tbDiag.Text += text;
}
}
This method gets called in any number of methods in my program to report stuff. Among them, it gets called in the ReportProgress of a BackgroundWorker: this happens periodically every few tens of milliseconds.
If I close the form (and the application) without stopping the BackgroundWorker, i get a System.InvalidOperationException because the TextBox has been disposed.
Is there a way to prevent this from the handler for the FormClosing event?
Either cancelling the running delegate or waiting for its completion would be fine, just as long as I can get to prevent that exception being thrown.
What I would like to avoid is having to keep a direct reference to the delegate.
I apologize if this was answered already somewhere else. I have been googling this to no avail.
Thank you.

C#: inner workings: events, Control.BeginInvoke and program exiting = Interruption?

I'm creating a program with several projects and some projects report back to the main project messages for logging purposes.
Since i am using Asynch sockets, some of these messages come back in different threads, so once they get to the main thread i check InvokeRequired and if true i use this.BeginInvoke to handle the logging.
I need to handle it in the UI thread specially in the case of the server, where i show the last logged messages on a ListBox so i can follow the progress of operations during my tests.
I know sometimes it may happen that a few messages get switched around, but for now i can live with that. For some reason if i use Invoke instead of BeginInvoke, the server will crash if i stop it while clients are connected, and won't even give any exception. But using BeginInvoke i overcame this.
My question regards understanding how events and BeginInvoke work in case of program termination. If an event is on queue or a BeginInvoke has been called just before the program is closed, will it terminate imediatly, cancelling everything? or will it perform all pending actions, in my case log the pending message, and then exit?

You'll have to delay closing the form if you want to ensure all BeginInvoked delegates are executed. You can do so by making it a two-step process, appending another BeginInvoke delegate to the queue that actually closes the form. Like this:
private bool closing;
protected override void OnFormClosing(FormClosingEventArgs e) {
if (!closing) {
closing = true;
// Do your stuff
//...
this.BeginInvoke(new Action(() => this.Close()));
e.Cancel = true;
}
base.OnFormClosing(e);
}

When you call BeginInvoke to update UI, the code will be executed by a thread from the threadpool. And if the code raises an exception, it will only terminate the thread, not the whole application. That's why you have seen that your program didn't crash.
When BeginInvoke had just been called, and the program was terminated immediately. The remaining operations (logging ) won't be executed, because the thread from the threadpool

Show dialog after Application.Exit()

Under certain circumstances, I wish to display an error message to the user if the application didn't shut down properly, but MessageBox.Show() doesn't actually do anything after calling Application.Exit(). Is there a way to convince it to show a dialog after Application.Exit()?

You will have to use a parent process that launches the Application. When the Application returns the return value is available to the parent process. If the return value of the Application is non-zero (not a success), then show the MessageBox from the parent process.

I'm assuming this is a window's app, so in the Program.cs you could the code below ... this assumes you create a public prop or field 'ExitOk' and set as needed in the mainform.
MainForm mf = new MainForm();
Application.Run(mf);
if (mf.ExitOk)
{MessageBox.Show("Exiting OK");}
else
{MessageBox.Show("Exiting Not OK");}
One point to note is that you might need to set mf to NULL or something like that at the end also.
Any one else want to comment on any other 'clean up' that might be need?

Nothing gets called after Application.Exit(). Application.Exit() does not return (unless the exit is canceled), it exits the application. After calling Application.Exit() the process is no longer running, so there is no way to get code to run after your processes has exited.
Does you code call Application.Exit()? If so change you calls to Application.Exit() to call MyApplication.Exit() where MyApplication is:
public static class MyApplicaiton {
public static void Exit() {
MessageBox.Show("Exiting Message");
Application.Exit();
}
}

Before exiting, the application fires the ApplicationExit event (WinForms) or Exit event (WPF). As part of your event handler code, you can show messsage boxes, for example. For example, in my application I show a "Do you want to save the unsaved changes?" dialog box, if applicable.
Note that it is not possible to cancel the exit in the event handler.

So far, I haven't been able to find much info on this problem. However, I did find a seemingly relevant discussion here. After a bit of research, I managed to find something of a solution, but it only allows you to use message boxes in your Main function after the initial Application.Run call has returned.
Note: All the following investigation has been done under .Net Framework 4.5.
From the forum discussion, it looks like calling Application.Exit in a window thread after calling Application.Run(Form) causes the Application system to move into a shutdown state. In this state, no new calls to Application.Run(Form) will work and no message boxes can be shown. On the other hand, if you call Application.Exit from a window thread after calling Application.Run(new ApplicationContext()) or just Application.Run(), this situation does not happen. It is okay to call Application.Run again and message boxes work like normal.
After a bit of experimentation, I found that if you call Application.Run() (no form) after entering the shutdown state, two things happen. The first is that the Application.Run() call immediately exits. The second is that shutdown state is cleared and regular behavior is resumed. This is great, but it presents a problem: if you have not called Application.Exit from your form, the formless Application.Run() call will block indefinitely as it waits for one to occur.
To solve this, you can use the Application.Idle event to rescue yourself from the blocked state. At first I tried:
Application.Run(new Form1()); // Calls Application.Exit()
Application.Idle += (o, e) => Application.Exit();
Application.Run();
MessageBox.Show("Close, but no banana...");
But for whatever reason, in this case the Application.Exit() call behaves similarly to if you were calling Application.Exit() while inside a Application.Run(Form) call. We run into the same situation where message boxes don't show and subsequent Application.Run calls don't work.
A bit more experimentation, and I found that the following does work:
Application.Run(new Form1()); // Calls Application.Exit()
Application.Idle += (o, e) => Task.Run(() => Application.Exit());
Application.Run();
MessageBox.Show("I'm alive!");
It's a bit ugly, and it looks purely nonsensical for anyone not in the know, but it seems to get the job done. Message boxes work as expected and it is possible to call either of the Application.Run functions again.
One last thing I should note is that it seems Application.Exit calls are queued. That is to say, you must call Application.Run() once for every time Application.Exit is called inside the form thread in order to clear the shutdown state. So if it is possible that your program may call Application.Exit multiple times, then the above solution won't work.
I haven't tested the following, but something like this should work if you're dealing with multiple Application.Exit calls:
Application.Run(new Form1()); // Calls Application.Exit() multiple times
bool done = false;
while(!done)
{
// Application.Idle is cleared after each run
Application.Idle += (o, e) =>
{
done = true;
Task.Run(() => Application.Exit());
};
Application.Run();
}
MessageBox.Show("I'm alive!");
At this point, it's probably better to wrap this in some sort of helper function, but I'll leave that up to the developer's preference.
In any case, I hope this helps anyone else who runs into this problem. The Application.Run behavior seems awfully irregular, so I'm going to assume this is a bug. But if anyone else wants to take up the investigation on this, you're more than welcome.

Winforms application hangs when switching to another app

I believe I have a potential threading issue. I have a user control that contains the following code:
private void btnVerify_Click(object sender, EventArgs e)
{
if (!backgroundWorkerVerify.IsBusy)
{
backgroundWorkerVerify.RunWorkerAsync();
}
}
private void backgroundWorkerVerify_DoWork(object sender, System.ComponentModel.DoWorkEventArgs e)
{
VerifyAppointments();
}
private void backgroundWorkerVerify_RunWorkerCompleted(object sender, System.ComponentModel.RunWorkerCompletedEventArgs e)
{
MessageBox.Show("Information was Verified.", "Verify",
MessageBoxButtons.OK, MessageBoxIcon.Information);
CloseEvent();
}
vanilla code. but the issue I have is that when the application is running and the users tabs to another application when they return to mine the application is hung, they get a blank screen and they have to kill it. This started when I put the threading code. Could I have some rogue threads out there? what is the best way to zero in a threading problem? The issue can't be recreated on my machine...I know I must be missing something on how to dispose of a backgroundworker properly. Any thoughts are appreciated, Thanks,
Jose

Your code snippet doesn't explain it, but deadlocking the UI thread is never that difficult when you use BGW and are interested in its IsBusy property. A deadlock like this is usually easy to diagnose, use Debug + Break All. Then Debug + Windows + Threads and double-click the Main Thread. Then Debug + Windows + Call Stack to see what the UI thread is doing.
The common scenario is that the UI thread is looping on the IsBusy property. The BGW can't complete because its RunWorkerCompleted event can't run until the UI thread goes idle.

Are you accessing the GUI from the VerifyAppointments() method? You should utilize the DoWorkEventArgs in order to pass in the arguments you are verifying and you should not access the GUI from the BackgroundWorker directly.
You can safely access the GUI only in the RunWorkerCompleted or the ProgressChanged events.

DragDrop registration did not succeed

System.InvalidOperationException: DragDrop registration did not
succeed. ---> System.Threading.ThreadStateException:
What does this exception mean? I get it at this line trying to add a panel to a panel at runtime...
splitReport.Panel1.Controls.Add(ChartPanel);
Working in VS2008 C#

This exception means that the thread that owns the Panel (the Panel being added) has been initialized using the MTA threading model. The drag/drop system requires that the calling thread use the STA thread model (particularly it requires that COM be initialized via OleInitialize). Threading models are an unfortunate vestige of COM, a predecessor of the .NET platform.
If you have the [STAThread] attribute on your Main function, then the main program thread should already be STA. The most likely explanation, then, is that this exception is happening on a different thread. Look at the Threads window in Visual Studio (Debug | Windows | Threads) when the exception occurs and see if you are on a thread other than the main thread. If you are, the solution is probably as simple as setting the thread model for that new thread, which you can do as follows (add this code to the thread where the control is being created):
Thread.CurrentThread.SetApartmentState( ApartmentState.STA )
(Thread and ApartmentState are members of System.Threading)
That code will need to happen before you actually start the new thread. As noted by #Tomer, you can also specify this declaratively using the [STAThread] attribute.
If you find that the exception is happening on the main thread, post back and let us know, and maybe we can help more. A stack trace at the time of the exception may help track down the problem.

function abc
{
Thread t = new Thread(new ThreadStart(xyz));
t.SetApartmentState(ApartmentState.STA);
t.Start( );
}
function xyz
{
the code of Windows form..or whatever which is causing the error
}

Add the STAThreadAttribute attribute on the Main method. This attribute is required if your program access OLE related functions, like Clipboard class does.
[STAThread]
static void Main(string[] args)
{
}

I'm not sure whether you have solved this problem or not. I just encountered this problem and I fixed it by deleting my bin directory.

Yes, I realize this question was asked 2 and a half years ago. I hit this exception and did some reading on it. I corrected it, but didn't see my solution anywhere, so I thought I'd post it somewhere someone else could read.
One possibility for this happening with [STAThread] marked on the Main() is if you're running this on a thread other than the one you started on.
I just ran into this exception when trying to create and show a new form in a BackgroundWorker.DoWork method. To fix it, I wrapped the creation and showing of my new form into a method, and then called Invoke on that method so that it fired on the UI thread. This worked because the UI thread started from the Main() method with [STAThread] marked, as other answers here explained.

This error also can happen, if you have async Task signature on your Main()
[STAThread]
static async Task Main()
{
}
if it's feasible change it back to void
[STAThread]
static void Main()
{
}

By far the easiest way is:
private void DoSomethingOnGui()
{
if (this.InvokeRequired)
{
this.Invoke((MethodInvoker)delegate
{
Safe_DoSomethingOnGui();
});
}
else
{
Safe_DoSomethingOnGui();
}
}
private void Safe_DoSomethingOnGui()
{
// Do whatever you want with the GUI
}
You can even pass things along no problem:
private void DoSomethingOnGui(object o)
{
if (this.InvokeRequired)
{
this.Invoke((MethodInvoker)delegate
{
Safe_DoSomethingOnGui(o);
});
}
else
{
Safe_DoSomethingOnGui(o);
}
}
private void Safe_DoSomethingOnGui(object o)
{
// Do whatever you want with the GUI and o
}

I solved this error by using below code...I were using Background Worker and trying to access UI while background worker..that is why getting error - DragDrop registration did not succeed.
We cannot access UI from the code running in background worker or in thread.
BeginInvoke((MethodInvoker)delegate
{
//write your code here...
});
Thanks Happy Coding... :

I found this error, and the one that makes the error shown was when we have another thread calling MessageBox.Show(this, ...). However, this is not done initialized.
We need to remove the owner of the message box to remove the error.

"Crypto Obfuscator For .NET" can also trigger this exception, in my case the DragDrop event was subscribed to (from designer), but contained no code as I commented it out much earlier on. It took a while to figure out what is was, and this was after changing every single Obfuscator config option 1 after the next.. it came down to exactly this. If you encounter this with a popular obfuscation tool, keep this in mind.

I have encountered this situation recently,[STAThreadAttribute]is in my case,and i solved this problem by using Invoke method,it might be helpful for you guys,so I share with a little code snippet:
this.Invoke(new InvokeHandler(delegate()
{
//Your method here!
}));
And InvokeHandler is a delegate like this:
private delegate void InvokeHandler();