Error - Cannot access a disposed object."

I have run into an error while using Sanddock (Version 2.3.3.1). After floating a window and then redocking I would occasionally get a "Cannot access a disposed object" exception. I noticed that the stack trace for the exceptions were always the same.


at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Form.CreateHandle()
at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.ToolTip.get_CreateParams()
at System.Windows.Forms.ToolTip.CreateHandle()
at System.Windows.Forms.ToolTip.Hide(IWin32Window win)
at System.Windows.Forms.DataGridView.DataGridViewToolTip.Activate(Boolean activate)
at System.Windows.Forms.DataGridView.OnMouseLeave(EventArgs e)


That led me to notice that the stack always contained a tooltip and datagridview object. I was able to consistantly reproduce the problem by creating a UserTabbedDocument that contains a datagridview with at least one column and has the tooltip property set on at least one column. Then if the UTD is floated, and then redocked, the exception should occur. Has anybody else experienced this? Is it possible to have this fixed in the next release?


Thanks

I have this issue in a number of SandDock applications at the moment and have been struggling to find a solution. From what I understand, the tooltip on the DataGridView has its internal Parent property set on creation and it does not get updated should the parent change. When you float a window, the contents is placed in a new, floating container. It would seem that the tooltip does not respond to this and so attempts to access its old, disposed parent. This issue is not necessary limited to the DataGridView control, although that is where I have been seeing it the most.

If this assessment is anywhere near correct then it is not strictly a fault with the SandDock component, however it is an issue that needs to be addressed. If floating and docking is unreliable for any control that features a DataGridView then it's something of a problem.

Incidentally, I was surprised to see the disposed object name returned as "\a". I didn't hear a bell so I guess this object came from obfuscated code. That really makes the development and debugging process easier.

I hope that someone can offer some assistance on this issue, thank you very much.

The best way to get this fixed is to report the bug to Microsoft. We have done this already but the more people that do, the more they will take this seriously.

An easy way to reproduce the bug (SandDock not required) is attached - just follow the simple steps and you can see that the ToolStrip control has a nasty bug where you cannot move it from one form to another without a subsequent attempt to show a tooltip blowing up.

"Blame Microsoft". Who didn't see that coming?

It's a valid assessment to be fair, but I'm sure there are people out there who are looking for a workaround rather than a place to direct their bug reports. For those people, just bear in mind that this issue is caused when a problematic control, maybe a DataGridView or a ToolStrip, is assigned a new parent. This happens as standard during the docking/floating process. Therefore, the best workaround is to ensure that you do not place these problematic controls directly onto your form / user control. Instead, define a container such as a Panel and ensure that your controls are placed in this container, which can then go on your form / user control. When the form/control is docked/floated, the parent of the DataGridView/ToolStrip/Whatever will not change - it will still be your content Panel.

The ToolStrip example was useful. It highlights how much easier it is to debug code that is not obfuscated.

Ben, I'm having trouble gauging the level of sarcasm in your post.

If I knew of a workaround for this issue I would tell people. The workaround you suggested does not have any effect in my tests.

I assume you used http://connect.microsoft.com/ for reporting the error to Microsoft. Could you please tell us the title of the bug (or at least some keywords) so that we can find it and vote on it?

Thanks,
Horst

I don't believe the bug is listed on there - it must have been LadyBug or BetaPlace.

Is there still nothing that can be done to avoid the "Cannot access a disposed object" error?

I have just recently started using SandDock in my application and am seeing this issue on a regular basis.
My docking window must contain the datagridview and a tool tip is available on that grid.
I know that has seemed to be a common set of controls that have caused people to have an issue although it appears that this combination is not required to get this problem to occur.

I wanted to see if there was any possible work around for this or anything being done or any word from Microsoft on getting this issue resolved.

Thanks.

I've re-submitted the bug, you can vote on it at the URL below. Unfortunately I don't believe there is anything we as control vendors can do to suppress this exception - this is a clear-cut bug in Windows Forms.

If this is a blocking issue I suggest you open an incident with Microsoft Product Support Services. They have the power to get the product team to look at this and possibly provide a hotfix, whereas the bug on Connect will result in a fix in the Orcas/.NET 3.5 timeframe (best case). Be sure to send the example application I created, if you do open a PSS case.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=265779

I went out the Microsoft Connect site yesterday and voted on the issue you had posted and left some feedback as well.

I noticed today that there is a response from the Visual Studio Team:
"Thanks for your feedback. We have reproduced this bug on Visual Studio 2005 SP1, and we are sending this bug to the appropriate group within the Visual Studio Product Team for triage and resolution.

They came back saying they have a fix in the next version of .NET. I've asked for clarification that this is indeed in Orcas.

Again, if you need a fix sooner I suggest contacting PSS about this - they may well b able to get that code into a hotfix for you.