InvalidOperationException: The object is currently in use elsewher

[Guest]

I have a DataGrid control on a Form. The data of the control is added by
another application by Remoting.
It means that a worker thread is invoking a UI thread. Therefore I used a
delegate in the Form invocation like this:
public delegate void AddDefectEventHandler(string xmlDefect);

public void AddDefect(string xmlDefect)
{
this.Invoke(new AddDefectEventHandler(this.AddDefectUI), new object []
{xmlDefect});
}

private void AddDefectUI(string xmlDefect)
{
// Doing the DataGrid data adding
}

I don't know if it's a thread problem, but sometimes I get the following
exception:

"System.InvalidOperationException: The object is currently in use elsewhere.
at System.Drawing.Graphics.Dispose(Boolean disposing)
at System.Drawing.Graphics.Dispose()
at System.Windows.Forms.PaintEventArgs.Dispose(Boolean disposing)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)"


Can anybody tell me what wrong?

 

[Yuan Ren[MSFT]]

Hi Sharon,

Welcome to MSDN newsgroup!

Based on my understanding and the error message, the current problem is
caused when the Graphics object is being used by other handles it calls
the Dispose method.

At the current stage, please check whether you use the object in other
parts of your project. Additionally, I recommend you make a simple demo
which can repro the current problem and send it to me. It¡¯ll help me to
narrow down the current problem. Thanks for your understanding! My alias is
(e-mail address removed) (remove .online).

I¡¯m looking forward your reply!

Regards,

Yuan Ren [MSFT]
Microsoft Online Support

 

[Guest]

I can send you the code I'm using, but to summarize will take some time.

The info I have right now is that I'm not using multithreading that uses the
DataGrid control.
I'm not using GDI+ of the DataGrid control at all.

After taking a closer look at the exception, you can see that the invocation
was initiated by the Windows OS (NativeWindow.Callback). So maybe it open a
new thread that access the control graphics outside the UI thread.

To prevent that, I override the OnPaint() of the DataGrid and locked with
the lock statement.
Furthermore; at this OnPiant() I'm checking if the calling thread is the UI
thread or other, so it is other thread then the UI thread I'll know I I'll
post in here.

Any other idea is more then welcome.

 

[Jeffrey Tan[MSFT]]

Hi Sharon,

Thanks for your feedback.

First, this is not caused by Windows OS code, but .Net winform FCL code.
(NativeWindow.Callback). Based on the call stack, the exception is caused
by .Net Winform code when it is processing WM_PAINT message for the form.

I am not sure if your finding of override the OnPaint of DataGrid is the
root cause. Does it resolve your problem?

Currently, I can find a known bug regarding this call stack. Based on the
bug details, it seems that it is caused by ATI Rage Pro driver, and
updating the driver fixes the problem. You may give this a try.

If you still can not workaround this problem, I think a reproduce little
sample is helpful for us to understand this issue. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Guest]

Hi Jeffrey,

Thanks for your reply.

I don't really understand what driver you want me to install (the ATI Rage
Pro driver). Is it the graphics board device driver? it sound like it should
be something higher then that.

Actually, I have this problem in tree of our control:
(1) Native .NET GroupBox control.
(2) DataGrid that is inside my own UserControl.
(3) My own MAP control derived from the UserControl.

*The first one we don't care about because its form windows is hidden.
*The second one did not occur yet since I locked the OnPaint() by deriving
the DataGrid and locking the call to the bas.OnPaint().
* The third is still happening, although I locked its OnPaint(), but it's
because I'm using the GDI+ in some more places of the MAP control code other
then its OnPaint().

In order to confirm my suspicion that the .Net winform FCL code
(NativeWindow.Callback) is calling from a NON UI thread, I warped the
Application.Run(new MyForm()) in a try-catch, and also added handling for
unhandled exceptions
(System.Threading.Thread.GetDomain().UnhandledException). in both the catch
exception I'm shown a MessageBox with the error. (This two handlers are at
the main form context).
Now the spoken exception was thrown again yesterday (Only in my MAP control)
BUT the two exception handling popped their MessageBoxes with the same
exception type and description AT THE SAME TIME (almost).

Therefore I'm quite sure that two threads was trying to use the GDI+ of the
control and one of them is not the UI thread. And as I mentioned before; I'm
not using any multi threading on the UI.
So my conclusion is that the .Net winform FCL code (NativeWindow.Callback)
do have a bug because it's invoking a UI call within a non UI thread.


Now I can prevent this error by locking all the code that uses any GDI+.

Maybe you have a better ideas?

 

[Guest]

Just to make sure:

Do I need to do Graphics.Dispose() / Image.Dispose() /
Graphics.ReleaseHdc(pDC) or should I let the garbage collector (GC) to do
that for me ?

Currently I'm disposing all the graphics objects that I'm using manually
(invoking the Dispose myself or using the using statement).

 

[Guest]

Some bad news...

The error was reproduce in our QA at the DataGrid itself although its
OnPaint() is protected by a lock.
Furthermore, the thrown exception was not caught nor by my try-catch around
the application Main function, nor by the unhandled exception catcher. It was
caught again by the CLR.

*** Important note: The QA PC has a dual Xeon dual core CPU, and this error
is only reproduced in that PC. But of course the QA PC does much more testing
then our development PC's.


Do you think it has anything to do with the dual CPU?

Does the .Net winform FCL code (NativeWindow.Callback) invoke the control
code from another thread?

 

[Guest]

More I thinks it's a bad new because it tells me that I can not bypass the
problem at hand.

I disabled 3 CPU's so only single CPU will execute my program (I did it
using the Windows Task Manager), Yes, after only a few hours it still
happened. Same exception!

Note: The QA PC does not have dual CPU dual core as I said before. It has
dual XEON CPU's with hyperthreading. And it's shown on the Task Manager as 4
CPU's.


Anyone can help here please ?

 

[Yuan Ren[MSFT]]

Hi Sharon,

Sorry for late response!

At the current stage, this issue would be a product problem, if you need a
solution to work around this problem, it is better for you if one of our
PSS support engineers could work with you. This may need you submit a
support incident in Microsoft PSS (Product Support Service). As a MSDN
subscriber, you have two free support incidents.

By the way, if the problem is confirmed by Microsoft PSS as a product
issue, PSS won't charge money. Every MSDN subscriber has two free support
incidents. You could use one of them to contact Microsoft PSS. So you don't
need to pay money yet. Surely if the issue is a product issue, you still
have two free support incidents.

For your reference, I attached steps to contact Microsoft PSS here: You can
contact Microsoft Product Support directly to discuss additional support
options you may have available, by contacting us at 1-(800)936-5800 or by
choosing one of the options listed at

http://support.microsoft.com/common/international.aspx?rdpath=gp;en-us;offer
prophone

Regards,

Yuan Ren [MSFT]

Microsoft Online Support