What issues can lead to a control with a red cross? / The object is currently in use elsewhere
Michael Groeger
I am having a strange problem in my application. I have implemented
some kind of grid control. I also implemented a really simple control
called SimpleCell which fills most cells of my grid.
From time to time - and the time between can really be large - I get
an System.InvalidOperationException with the additional information:
"The object is currently in use elsewhere". This comes always with a
big red cross being drawn inside of one of the controls on the grid.
I figured out that the essence of this exception is, that one object
is currently modified or accessed by one or more threads at one time.
I looked all over my grid implementation and found out, that there
cannot (obviously) occur such a concurrent modification. Because of
that - and the fact that somebody draws a red cross into my control -
I think something strange must happen inside the OnPaint handler of my
SimpleCell control. Here it is:
Protected Overrides Sub OnPaint(ByVal e As PaintEventArgs)
Dim g As Graphics = e.Graphics
Dim r As Rectangle = ClientRectangle
Dim rf As New RectangleF(0, 0, r.Width, r.Height)
Dim p1 As New Pen(Color.Gray)
Dim p2 As New Pen(Color.LightGray)
Dim sf As StringFormat = New
StringFormat(StringFormatFlags.NoWrap)
' apply alignment
If (Align = Alignment.Center) Then
sf.Alignment = StringAlignment.Center
ElseIf (Align = Alignment.Left) Then
If (Me.RightToLeft = RightToLeft.Yes) Then
sf.Alignment = StringAlignment.Far
Else
sf.Alignment = StringAlignment.Near
End If
Else
If (Me.RightToLeft = RightToLeft.Yes) Then
sf.Alignment = StringAlignment.Near
Else
sf.Alignment = StringAlignment.Far
End If
End If
sf.LineAlignment = StringAlignment.Center
' draw lines
g.DrawLine(p1, 0, 0, r.Width - 1, 0)
g.DrawLine(p1, 0, 0, 0, r.Height - 1)
g.DrawLine(p2, r.Width - 1, 0, r.Width - 1, r.Height - 1)
g.DrawLine(p2, 0, r.Height - 1, r.Width - 1, r.Height - 1)
' draw text
g.DrawString(Me.Text, Me.Font, New SolidBrush(Me.ForeColor),
rf, sf)
End Sub
All methods which may change values of cells inside my grid control
are normally synchronized, so that it should not even be possible to
update a row or cell parallel at one time with two threads.
I would like to provide you more debugging/disassembly information,
but as I already mentioned, phases between occurrences of this problem
can be very large. For now I am waiting three days for it to happen,
but nothing happens. Anyways, the problem is critical, as the software
is used on a time critical market.
Maybe somebody directly solves my problem by directing to a bug in my
code, but if not, I would appreciate any information of people who
know this problem and can give me hints.
Kind regards,
Michael
Bob Powell
This is the common response of the system when it finds a problem with a
control at design time. Your grid control build may be out of date or may
have failed or the control may be active in the designer toolbox so that it
cannot be written to by the build process.
You should always build your control in one solution and test it in another.
Never attempt to build a control and test it in the same instance of VS.NET.
Build your control as a DLL, Select the solution properties and ensure that
debug mode is set to "program" and that the start application is set to
"C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE\devenv.exe" (if
you have accepted the default IDE install)
When you have set this up, debugging the DLL will create a clean build of
the library and then invoke a second copy of the VS IDE that you can use to
test your control. Remember to close the second copy of the IDE completely
before re-editing and re-testing your control. If the library doesn't build
error free, you'll have to fix those errors before the second copy of VS.NET
gets loaded.
Bob.
--
Have you thought about buying my book?
http://www.amazon.com/exec/obidos/ASIN/067232153X/bobpowelnet
Looking for something else? Check out my .NET book recommendations.
http://www.bobpowell.net/recommendations.htm
Visit NetEdge Software to find out about the Web Service Enabler.
Enable all your legacy C++ and VB6 applications to seamlessly connect to
.NET and Apache Axis web-services.
http://www.netedgesoftware.com
"Michael Groeger" <michael...@tria.de> wrote in message
news:5e2c05.020918...@posting.google.com...
Michael Groeger
thanks for your reply.
> This is the common response of the system when it finds a problem with a
> control at design time. Your grid control build may be out of date or may
> have failed or the control may be active in the designer toolbox so that it
> cannot be written to by the build process.
This may be write, but the grid is not visible at design time, as it
is added at runtime. The problem happens sometimes at runtime and I
was able to break down the problem to the Text property. Unfortunately
setting the Text property does not automatically invalidate and update
the client area of a UserControl. So I had to override the Text
property and Invalidate() and Update() the client area by hand. This
seems to be the problem, as we are in a multithreaded environment.
Update() invokes the Paint-event but asynchronous. So the Text
property is left, before the paint handler even gets called.
If you take a look at the last line of my code...
g.DrawString(Me.Text, Me.Font, New SolidBrush(Me.ForeColor), rf,
sf)
...you might see the problem. So I added now synchronization to the
Text propery. I hope it helps, but I am not quite yet sure.
> You should always build your control in one solution and test it in another.
> Never attempt to build a control and test it in the same instance of VS.NET.
Okay, I will remember that when I build a control, which I can use at
design time.
Kind regards,
Michael