Red X In GoView

GoDiagram (6 and previous)
1

I am laying out nodes on a GoLayoutForceDirected component. As my application adds Iconic Nodes to the Layout occasionally I will get a big red x on the layout. How do I track down this problem in my code?

Also, I have another problem where sometimes the icons do not get displayed on the layout. I can step through the code and see the links get set and the nodes are added but I don’t actually see anything on the screen.

2

If you are on Windows Forms, I can’t explain that.
If you are on Web Forms, then there may be a delay or error getting the image from the web server. Perhaps if the layout takes too long it’s unable to generate the image because the data structures are locked.

3

I am using the dot net windows forms and I am getting a big red x across the visualization sometimes.

4

That’s pretty weird. What’s odd is that the layout methods don’t do any painting, so it must be something else that is drawing a big red X. I know there isn’t any code in GoDiagram like that. It’s plausible that System.Windows.Forms.Controls do that in some circumstances, though.
Can you supply a screenshot? (You can email it to us if you want.)
Does the border appear correctly? (You might find it hard to tell.)
Do you override any painting methods on GoView or GoObject?

5

Next time it happens I will get a screenshot of it and send it to you.

6

Sorry to reply to an old post. I came across this while doing a search, but i have some info that might help…



You will get a Red X drawn inside a red Rectangle when a control process a WmPaint or WmEraseBkgnd message and and unhandled exception occurs inside either the OnPaint or OnPaintBackground methods. Since the framework catches and handles the exception (by drawing the red X) you don’t usually get a chance to see what is going because no unhandled exception dialog is displayed.



If you have a way to consistently repro it then attaching the debugger and setting it to break on all exceptions can sometimes be a good way to track down the underlying cause.

7

ianc that is exactly what is happening, I have tracked down the problem to

the OnPaint event, does anyone know how to prevent this?

8

Again, I must say I haven’t seen any such errors.
Are there any trace messages?
GoView.OnPaint does all of the painting within a try-catch; the catch puts out a trace message. The Output window in Visual Studio is a Trace Listener. You can also implement your own in your application.
Can you do as “ianc” suggests and use the debugger to break on all exceptions?
FYI, GoView.OnPaintBackground is a no-op, since GoView does it own background painting.

9

Walter I do have a screenshot I can send you, where should I email it
to. I can’t attach to the process because the software works fine
on my development machine, but the error appears on a multiprocessor
box I do not have access to.

10

GoDiagram
I know that one of us has been developing on a two-processor machine for many months on a graphics-intensive project using GoDiagram Win, and he hasn’t seen any problems.
Do you use any (additional) threads in your application? Might any of them be accessing any Controls (including GoView) without explicitly synchronizing with the UI thread?

11

Walter I sent you an email. The application is highly threaded,
but only one of them should be writing to the visualization.

12

Yes, that seems to be the problem. Note that the error message says “System.InvalidOperationException: The object is currently in use elsewhere.”
That’s a clear sign there’s some kind of threading problem in your application.
For your information, if you modify a GoDocument or a part of a GoDocument (such as a GoObject in the document), all updates to the GoView go through a GoDocument.Changed event handler in the GoView that should be thread-safe.
However, your code might be looking at System.Drawing data structures in your other thread(s). That would be a Windows no-no. Maybe you are looking at some Pen or Brush.

13

I’m getting a similar problem with my application. I’m getting a “System.OutOfMemoryException” and then a big red x in the view. Have you seen this problem before? It’s occurring in the GoShape.DrawEllipse call.

14

We have over the years occasionally had to add work-arounds for what appear to be bugs in GDI+. One such kind of bug is trying to draw very small curves. Can you tell what size ellipse you are trying to draw?

15

I used to have such a kind of problem on bi-processor computers when we were issuing so command to GoDiagram that caused a repaint from a thread other than the thread that created the GoView. Correcting that corrected the problem.

16

I’m getting the OutOfMemory exception again, although this time it is during the GetBitmapFromCollection() call of the GoView. Any idea what might be happening? It seems to happen when there are a lot of lines to draw.

17

Here’s the stack trace of the exception:

I'm drawing around 11,000 lines between 3500 nodes. Some of the nodes are pretty small, and some lines are pretty short.
Exception: System.OutOfMemoryException
Source: System.Drawing
Message: Out of memory.
StackTrace: at System.Drawing.Graphics.CheckErrorStatus(Int32 status)
at System.Drawing.Graphics.DrawPath(Pen pen, GraphicsPath path)
at Northwoods.Go.GoShape.DrawPath(Graphics g, GoView view, Pen pen, Brush brush, GraphicsPath path)
at Northwoods.Go.GoStroke.Paint(Graphics g, GoView view)
at Northwoods.Go.GoGroup.Paint(Graphics g, GoView view)
at Northwoods.Go.GoView.GetBitmapFromCollection(IGoCollection coll, RectangleF bounds, Single scale, Boolean paper)
18

How large is the bitmap supposed to be? Maybe it really is too big.

I think you can get the same exception when the width and/or height is zero, too.
I bet there are other GDI+ problems that cause odd exception messages. We keep finding more.
19

The image is pretty big (5000p x5000p x32bpp), but it should still fit into memory.

20

100 MB? Maybe… Try modifying your application to make a test bitmap, not involving GoView, draw some random stuff to it, and see if everything works OK on output.