Skip to main content

ToolTip and "Cannot access a disposed object" exception

The "Cannot access a disposed object" exception is a nightmare for .NET developers. ;) Sometimes, this exception causes the worst backslash for a development project. And looking at exception details, we will find that the call stack will point to

"at System.Windows.Forms.Control.CreateHandle()
 at System.Windows.Forms.Control.get_Handle() "


"at System.Windows.Forms.Form.CreateHandle()
 at System.Windows.Forms.Form.get_Handle() "

Since, we do not know from where the problem stems, it becomes a trial-and-error method to find out the source of the problem. After some days of research, I found out the following facts about the problem. Here it goes.

Reason :

   This exception occurs only when we try to access any disposed object, as it says. But the problem is, we would have never written statements that explicitly access a disposed object! So the real reason would be some unseen code that accesses the disposed Form or Object. In my case, the black sheep was the ToolTip control.

   I had used the ToolTip to show messages on different forms. But the internal architecture of the ToolTip has been coded by a novice at Microsoft i guess, and its faulty. By going through reflection i found that it uses a variable to store the current form in which it the message is being displayed. I had used the same instance of ToolTip to show messages on other forms too. When I used the ToolTip to show messages on another form after the previous form has been closed, the ToolTip tries to access the form in its private variable (the closed/disposed form) and boom! It throws the exception!

   Another instance where this can happen is - Dockable Container, this happens with ToolTip when the container is changed/docked to another parent. Now since, the parent is changed, when the ToolTip tries to access the parent and it is already disposed. So the exception is thrown.


   The solution I devised was to create a new ToolTip instance for every Form that I showed on the screen. This worked around the problem and it was solved. For those, with Dockable Container problem, try to recreate the controls when they are moved or docked. This will solve the problem.

   And microsoft is supposed to have corrected this problem in v3.5 framework. But I haven't checked it out yet.


hmmm "creating new instance" everytime worked for me...thanx man..
Johnny Avacado said…
The problem has not been fixed in the 3.5 Framework.
Jey Geethan said…
It's sad to know that the problem still persists in 3.5 framework.
Bhuttoo Ashvin said…
I am using .Net 4.5.2 and this issue still persists..


Rails Engine - How To Keep Your Engine Migrations Abstracted From Your Host Rails App

Have you ever worked on building a Rails Engine and wanted to keep the models, the migrations and everything inside the engine rather than using a generator to copy paste them into your host Rails App? That's a problem everybody faces one time or the other when building Rails Engines to abstract out your huge Rails App. I have found one such solutions that can be helpful for you to keep them separate. Here is a solution for it.
Problem Statement: Instead of using

    rails g my_engine:install
to copy paste the migrations from engine to your rails app, you want to just keep the migrations inside the Rails Engine and do not bother about it.
Solution:  Add the following lines to your engine, so that your engine's migration files are added to the rails app as well.

Now you can do the following from your rails app to run your migrations as you always do:

rake db:migrate
Hope it helps you! If it does help you, give me a shoutout below!

Talk to me on Twitter, Facebook, LinkedIn or Web…
You will receive wonderful short stories written by him and inspirational articles once every month.