I'm having 2 forms. From one form I created and shown the other form. It's working great. But when I try to close or Dispose that form from the form that created it I get following Exception:
Exception :
Value Dispose() cannot be called while doing CreateHandle().
Stack Trace :
========================
at System.Windows.Forms.Control.Dispose(Boolean disposing)
at System.Windows.Forms.Label.Dispose(Boolean disposing)
at System.ComponentModel.Component.Dispose()
at System.Windows.Forms.Control.Dispose(Boolean disposing)
at System.Windows.Forms.ContainerControl.Dispose(Boolean disposing)
at System.Windows.Forms.Form.Dispose(Boolean disposing)
at Speedometer_Application.frmSpeedometer.Dispose(Boolean disposing)
Any idea????
The error Value Close() cannot be called while doing CreateHandle() usually happens when we try to close the form in the constructor or Load event.
For example, the following code gives the error:
private void frmCustomer_Load(object sender, EventArgs e)
{
if (!Valid())
this.Close;
}
The Solution:
private void frmCustomer_Load(object sender, EventArgs e)
{
if (!Valid())
this.BeginInvoke(new MethodInvoker(Close));
}
You can use this in your code.
it is hard to say what is the problem from the code you posted.
The code that you posted should work (form shown with Show() should be possible to close with Dispose() method).
The reason why it does not work is probably somewhere in the form that you are trying to dispose of. When you call Dispose() method (according to the error message this is what happens) on an object, that object will try to dispose of all its children and do some cleanup. That is the place to look for error.
My suggestion is to comment out all your code in the form objfrm (or make new EMPTY form) and see if error happens. It should not happen. Then start adding commented code and see when the error happens. I bet it will be in the code that is being called as consequence of Dispose method.
The code is as follows:
if (frmMain.objfrm== null)
{
frmMain.objfrm = frmMyForm.Instance;
frmMain.objfrm.ShowInTaskbar = false;
}
frmMain.objfrm.Show();
frmMain.objfrm.BringToFront();
frmMain is the Main Form that has a static variable of the frmMyForm. than in my code whereever i want to use this I just check if it's not null than create it using a static Instance and than give the peoperty.
While closing the form I have the following code:
frmMain.objfrm.Close_this();
The Close_this calls the Close() or Dispose() method.
But when I call that function I get the above exception.
You need to use ShowDialog instead of Show thats the problem. Show dont block the application and the code keeps running.
You are disposing the object when the GUI is creating it (that what the exception said)
Try with this:
if (frmMain.objfrm== null)
{
frmMain.objfrm = frmMyForm.Instance;
frmMain.objfrm.ShowInTaskbar = false;
}
frmMain.objfrm.ShowDialog();
Note the ShowDialog()
Related
Since Pipe_Disconnected is called by another thread, MainWindow.Close must be called by Dispatcher.
What is the difference between the codes below?
I am using .Net7.
Work
private void Pipe_Disconnected(object sender, object e)
{
Application.Current.Dispatcher.InvokeAsync(() => Application.Current.MainWindow.Close());
}
Not Work
private void Pipe_Disconnected(object sender, object e)
{
Application.Current.Dispatcher.InvokeAsync(Application.Current.MainWindow.Close);
}
Not Work
private void Pipe_Disconnected(object sender, object e)
{
var temp = new Action(Application.Current.MainWindow.Close);
Application.Current.Dispatcher.InvokeAsync(temp);
}
The practical difference when Application.MainWindow is being accessed.
In the first example, the property is accessed in dispatcher thread.
In the second and third it is accessed from another thread.
If you examine stacktrace of the exception, you won't see the Close method, because it is never called. The Exception is thrown when accessing MainWindows instance. The Dispatcher. InvokeAsync won't even get a chance so be called.
I'm building a WPF application using the SimpleMVVM framework and I'm having trouble catching exceptions. I use the MessageBus of SimpleMVVM to send a message to another viewmodel. This all works fine, but I noticed that exceptions raised in the code executed by the messagebus get suppressed. Here's what I've got so far:
My MainWindow contains a button that fires a TempCommand on the MainWindowViewModel. This command in turn calls the Test method (shown below), which sends out a notification message using the MessageBus of SimpleMVVM.
private void Temp()
{
SendMessage("Temp", new NotificationEventArgs());
}
My MainWindow also contains a Frame with content. The ViewModel of this content, CustomerViewModel, has registered to receive these notifications in its constructor:
public CustomerDetailsViewModel(ICustomerServiceAgent agent)
{
RegisterToReceiveMessages("Temp", Temp);
}
Where the Temp method simply throws an exception:
private void Temp(object sender, NotificationEventArgs args)
{
throw new NotImplementedException("Somewhere, something horrible happened");
}
When I debug the application, I clearly see the Temp method being called and the exception being raised. But for some reason, that's all. The application is unaffected and my exception trapping code is unaware of the exception.
I trap exceptions in two ways. The first is by handling the event on the Dispatcher:
<Application x:Class="MyApp"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="MainWindow.xaml"
DispatcherUnhandledException="App_DispatcherUnhandledException">
Where the code-behind looks like:
private void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
{
Log("Exception: " + e.Exception.Message);
e.Handled = true;
}
public static void Log(string message)
{
File.AppendAllText(#"D:\Temp\log.txt", "[" + DateTime.Now.ToString("F") + "] [" + System.Threading.Thread.CurrentThread.ManagedThreadId.ToString() + "] " + message + Environment.NewLine);
}
This code catches some exceptions, but not all. I found out that WPF suppresses databinding exceptions by default. Because my ViewModels are bounded through the DataContext property on my view, I thought this was the problem. I found this article, which defines a TraceListener that uses the PresentationTraceSources class. Databinding exceptions now get caught, but... Not the exceptions thrown in the code executed through the MessageBus.
I've created a solution demonstrating this behavior, it can be downloaded here.
And this is where I'm stuck. What am I missing? How do I catch these exceptions?
Big thanks in advance.
JP
I think it is a bug or problem with the implementation of the MessageBus in SimpleMVVM.
Cause multiple subscribers can subscribe to a token, the current implementation ensures that each subscribed method gets called even when one registered method throws an exception. In this case the exception is catched and written out to the Console.
The method that is responsible to call a subscribed method is SafeNotify
private void SafeNotify(Action method, bool post) {
try {
// Fire the event on the UI thread
if (post){
if (Dispatcher.CheckAccess()){
method();
}
else{
Dispatcher.BeginInvoke(method);
}
}
// Fire event on a ThreadPool thread
else{
ThreadPool.QueueUserWorkItem(o => method(), null);
}
}
catch (Exception ex){
// If there's an exception write it to the Output window
Debug.WriteLine(ex.ToString());
}
}
When the method call gets queued in the ThreadPool, you have no chance to handle the thrown exception. See also this post for further information.
The only option you have is to ensure that the code of your own registered methods is always surrounded by a try-catch-block.
I have a WPF application that consists of multiple projects that have forms, classes, base classes, etc..
Because of the large code base I want to make sure if an exception does happen I can catch it, notify the user and let the application continue without crashing. I understand the pros and cons to doing this.
In the App.xaml.cs of the application I have:
private void OnApplicationStartup(object sender, StartupEventArgs e)
{
Application.Current.DispatcherUnhandledException += CurrentOnDispatcherUnhandledException;
AppDomain.CurrentDomain.UnhandledException += CurrentDomainOnUnhandledException;
Dispatcher.UnhandledException += DispatcherOnUnhandledException;
UI.Views.Windows.MainWindow.Show();
}
private void DispatcherOnUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs dispatcherUnhandledExceptionEventArgs)
{
MessageBox.Show("TEST 3");
}
private void CurrentDomainOnUnhandledException(object sender, UnhandledExceptionEventArgs unhandledExceptionEventArgs)
{
MessageBox.Show("TEST 2");
}
private void CurrentOnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs dispatcherUnhandledExceptionEventArgs)
{
MessageBox.Show("TEST 1");
}
If an exception happens anywhere those messages boxes are shown which is great, the problem is right after it shows the message the application still crashes. If I run the application in debug, Visual Studio will jump to the place were the exception happened and if I continue it will then go to the message box.
I think the problem has something to do with that but I am not sure. Is there a way to catch the exception like I am above but at the same time not have the application crash after?
Thank You
EDIT
The exceptions that get through to the UnhandledException section will be things like NullReference, NotSupported or Database Exceptions for the most park. If a "serious" exception gets cought like Stack Overflow I will simple notify the user and kill the app. I still need to find a way to stop the app from crashing on non serious exceptions though.
I think you need to set
dispatcherUnhandledExceptionEventArgs.Handled = true;
What kind of exception is your application catching? Using UnhandledException for exceptions that change state will not work unless you are setting HandleProcessCorruptedStateExceptionsAttribute attribute.
From MSDN documentation:
AppDomain.UnhandledException Event
Starting with the .NET Framework 4, this event is not raised for exceptions that corrupt the state of the process, such as stack overflows or access violations, unless the event handler is security-critical and has the HandleProcessCorruptedStateExceptionsAttribute attribute.
http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx
I have a SafeInvoke Control extension method similar to the one Greg D discusses here (minus the IsHandleCreated check).
I am calling it from a System.Windows.Forms.Form as follows:
public void Show(string text) {
label.SafeInvoke(()=>label.Text = text);
this.Show();
this.Refresh();
}
Sometimes (this call can come from a variety of threads) this results in the following error:
System.InvalidOperationException occurred
Message= "Invoke or BeginInvoke cannot be called on a control until the window handle has been created."
Source= "System.Windows.Forms"
StackTrace:
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
at DriverInterface2.UI.WinForms.Dialogs.FormExtensions.SafeInvoke[T](T control, Action`1 action)
in C:\code\DriverInterface2\DriverInterface2.UI.WinForms\Dialogs\FormExtensions.cs:line 16
What is going on and how do I fix it? I know as much as it is not a problem of form creation, since sometimes it will work once and fail the next time so what could the problem be?
PS. I really really am awful at WinForms, does anyone know a good series of articles that explains the whole model and how to work with it?
It's possible that you're creating your controls on the wrong thread. Consider the following documentation from MSDN:
This means that InvokeRequired can
return false if Invoke is not required
(the call occurs on the same thread),
or if the control was created on a
different thread but the control's
handle has not yet been created.
In the case where the control's handle
has not yet been created, you should
not simply call properties, methods,
or events on the control. This might
cause the control's handle to be
created on the background thread,
isolating the control on a thread
without a message pump and making the
application unstable.
You can protect against this case by
also checking the value of
IsHandleCreated when InvokeRequired
returns false on a background thread.
If the control handle has not yet been
created, you must wait until it has
been created before calling Invoke or
BeginInvoke. Typically, this happens
only if a background thread is created
in the constructor of the primary form
for the application (as in
Application.Run(new MainForm()),
before the form has been shown or
Application.Run has been called.
Let's see what this means for you. (This would be easier to reason about if we saw your implementation of SafeInvoke also)
Assuming your implementation is identical to the referenced one with the exception of the check against IsHandleCreated, let's follow the logic:
public static void SafeInvoke(this Control uiElement, Action updater, bool forceSynchronous)
{
if (uiElement == null)
{
throw new ArgumentNullException("uiElement");
}
if (uiElement.InvokeRequired)
{
if (forceSynchronous)
{
uiElement.Invoke((Action)delegate { SafeInvoke(uiElement, updater, forceSynchronous); });
}
else
{
uiElement.BeginInvoke((Action)delegate { SafeInvoke(uiElement, updater, forceSynchronous); });
}
}
else
{
if (uiElement.IsDisposed)
{
throw new ObjectDisposedException("Control is already disposed.");
}
updater();
}
}
Consider the case where we're calling SafeInvoke from the non-gui thread for a control whose handle has not been created.
uiElement is not null, so we check uiElement.InvokeRequired. Per the MSDN docs (bolded) InvokeRequired will return false because, even though it was created on a different thread, the handle hasn't been created! This sends us to the else condition where we check IsDisposed or immediately proceed to call the submitted action... from the background thread!
At this point, all bets are off re: that control because its handle has been created on a thread that doesn't have a message pump for it, as mentioned in the second paragraph. Perhaps this is the case you're encountering?
I found the InvokeRequired not reliable, so I simply use
if (!this.IsHandleCreated)
{
this.CreateHandle();
}
Here is my answer to a similar question:
I think (not yet entirely sure) that
this is because InvokeRequired will
always return false if the control has
not yet been loaded/shown. I have done
a workaround which seems to work for
the moment, which is to simple
reference the handle of the associated
control in its creator, like so:
var x = this.Handle;
(See
http://ikriv.com/en/prog/info/dotnet/MysteriousHang.html)
The method in the post you link to calls Invoke/BeginInvoke before checking if the control's handle has been created in the case where it's being called from a thread that didn't create the control.
So you'll get the exception when your method is called from a thread other than the one that created the control. This can happen from remoting events or queued work user items...
EDIT
If you check InvokeRequired and HandleCreated before calling invoke you shouldn't get that exception.
If you're going to use a Control from another thread before showing or doing other things with the Control, consider forcing the creation of its handle within the constructor. This is done using the CreateHandle function.
In a multi-threaded project, where the "controller" logic isn't in a WinForm, this function is instrumental in Control constructors for avoiding this error.
Add this before you call method invoke:
while (!this.IsHandleCreated)
System.Threading.Thread.Sleep(100)
Reference the handle of the associated control in its creator, like so:
Note: Be wary of this solution.If a control has a handle it is much slower to do things like set the size and location of it. This makes InitializeComponent much slower. A better solution is to not background anything before the control has a handle.
var that = this; // this is a form
(new Thread(()=> {
var action= new Action(() => {
something
}));
if(!that.IsDisposed)
{
if(that.IsHandleCreated)
{
//if (that.InvokeRequired)
that.BeginInvoke(action);
//else
// action.Invoke();
}
else
that.HandleCreated+=(sender,event) => {
action.Invoke();
};
}
})).Start();
I had this problem with this kind of simple form:
public partial class MyForm : Form
{
public MyForm()
{
Load += new EventHandler(Form1_Load);
}
private void Form1_Load(Object sender, EventArgs e)
{
InitializeComponent();
}
internal void UpdateLabel(string s)
{
Invoke(new Action(() => { label1.Text = s; }));
}
}
Then for n other async threads I was using new MyForm().UpdateLabel(text) to try and call the UI thread, but the constructor gives no handle to the UI thread instance, so other threads get other instance handles, which are either Object reference not set to an instance of an object or Invoke or BeginInvoke cannot be called on a control until the window handle has been created. To solve this I used a static object to hold the UI handle:
public partial class MyForm : Form
{
private static MyForm _mf;
public MyForm()
{
Load += new EventHandler(Form1_Load);
}
private void Form1_Load(Object sender, EventArgs e)
{
InitializeComponent();
_mf = this;
}
internal void UpdateLabel(string s)
{
_mf.Invoke((MethodInvoker) delegate { _mf.label1.Text = s; });
}
}
I guess it's working fine, so far...
What about this :
public static bool SafeInvoke( this Control control, MethodInvoker method )
{
if( control != null && ! control.IsDisposed && control.IsHandleCreated && control.FindForm().IsHandleCreated )
{
if( control.InvokeRequired )
{
control.Invoke( method );
}
else
{
method();
}
return true;
}
else return false;
}
I started a new WPF project in VS2008 and then added some code to trap DispatcherUnhandledException. Then I added a throw exception to Window1
but the error is not trapped by the handler. Why?
public App()
{
this.DispatcherUnhandledException += new DispatcherUnhandledExceptionEventHandler(App_DispatcherUnhandledException);
}
void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
{
System.Windows.MessageBox.Show(string.Format("An error occured: {0}", e.Exception.Message), "Error");
e.Handled = true;
}
void Window1_MouseDown(object sender, MouseButtonEventArgs e)
{
throw new NotImplementedException();
}
This can happen because of the way you have the debugger handling exceptions -- Debug/Exceptions... should allow you to configure exactly how you want it handled.
Look at following msdn link http://msdn.microsoft.com/en-us/library/system.windows.application.dispatcherunhandledexception.aspx
Following is Relevant here
If an exception is not handled on either a background user interface (UI) thread (a thread with its own Dispatcher) or a background worker thread (a thread without a Dispatcher), the exception is not forwarded to the main UI thread. Consequently, DispatcherUnhandledException is not raised. In these circumstances, you will need to write code to do the following:
Handle exceptions on the background thread.
Dispatch those exceptions to the main UI thread.
Rethrow them on the main UI thread without handling them to allow DispatcherUnhandledException to be raised.
This is how I handle it. This isn't pretty but keep in mind that this type of error should never make it past debugging as a dev. Those errors should be long resolved before you go to production (so its okay that this isn't pretty). In the Startup project, in the App.xaml (App.xaml.cs) code behind, I put the following code.
OnStartup, create a DispatcherUnhandledException event handler
In the handler, use a MessageBox to display the message. Note that its likely the startup window has not yet been created so don't try to put it in a window.
e.Handle the error
I like to see when there are additional internal errors so I continue to call the display window until the internal error is null.
I'm not sure why the code block special characters aren't formatting this correctly. Sorry about that.
protected override void OnStartup(StartupEventArgs e)
{
// define application exception handler
Application.Current.DispatcherUnhandledException +=
AppDispatcherUnhandledException;
// defer other startup processing to base class
base.OnStartup(e);
}
private void AppDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
{
runException(e.Exception);
e.Handled = true;
}
void runException(Exception ex)
{
MessageBox.Show(
String.Format(
"{0} Error: {1}\r\n\r\n{2}",
ex.Source, ex.Message, ex.StackTrace,
"Initialize Error",
MessageBoxButton.OK,
MessageBoxImage.Error));
if (ex.InnerException != null)
{
runException(ex.InnerException);
}
}
At first, even outside the debugging environment, my handler does not seem to be triggering.....then I realized I forget to set e.Handled = true.
In truth it was working but because e.Handled was still false the standard exception handler still kicked in and did its thing.
Once I set e.Handled = true, then everything was hunky dory. So if its not working for you, make sure you've done that step.
For those interested
It seems that the IDE is still breaking on exceptions and that if you click continue in the IDE it call the error handler.