Graphics exception

One of our customers has created a large diagram and now it is throwing this exception every time additional nodes are added:
“at System.Drawing.Graphics.GetHdc()
at System.Windows.Forms.Internal.WindowsGraphics.FromGraphics(Graphics g, ApplyGraphicsProperties properties)
at System.Windows.Forms.ControlPaint.DrawBorder3D(Graphics graphics, Int32 x, Int32 y, Int32 width, Int32 height, Border3DStyle style, Border3DSide sides)
at System.Windows.Forms.ControlPaint.DrawBorder3D(Graphics graphics, Rectangle rectangle, Border3DStyle style)\r\n at Northwoods.Go.GoView.PaintBorder(Graphics g, Rectangle rect, Rectangle clipRect)
at Northwoods.Go.GoView.onPaintCanvas(PaintEventArgs evt)
at Northwoods.Go.GoView.OnPaint(PaintEventArgs evt)
at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs)
at System.Windows.Forms.Control.WmPaint(Message& m)\r\n at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
at LANDesk.Workflow.Win.forms.mdi.Main() in E:\dev\ProcessManager\Applications\Autobahn\LANDesk.Workflow.Win\forms\mdi.cs:line 1141”

What is the fix?
Thanks,
Brian Kerr

How big is the GoView, and how big is that view’s GoDocument?

Also, what is the exception? You've shown the stack but not the error message.

<?:namespace prefix = v ns = “urn:schemas-microsoft-com:vml” /><v:shape id=_x0000_t75 stroked=“f” filled=“f” path=“m@4@5l@4@11@9@11@9@5xe” o:preferrelative=“t” o:spt=“75” coordsize=“21600,21600”> Sorry about that. The exception is “Paramter is not valid”. There are over 300 GoView objects. I would attach a screen shot, but it is over the 75K limit.</v:shape>

No, I meant, what is the GoView’s size – i.e. Control.Width and .Height?

But another possibility occurs to me now -- is there any chance that there is a threading problem?

Height-609, Width-533

Single threaded Windows forms

Well, that doesn’t sound very big at all, either in size of the GoView (which I thought might cause the ControlPaint error) or in the size of the GoDocument (either in dimensions or in number of GoObjects).
Do the scrollbars work OK, both before and after the exception?
If you change the GoView.BorderStyle to BorderStyle.FixedSingle or .None, does everything work well?

Changing the border to none did get rid of that error, but I quickly got a second error. I have attached the bitmap so you can look at it.

That’s happening even before the call to PaintBorder. The only time I’ve seen that error is when the width and/or height are zero or negative. Does GoView.ClientRectangle have a positive Width and Height at the time this exception occurs?

I'm assuming the exception is reliably reproducible, and you can debug it.

The exception is reproducible, and I can debug it to a point. The problem is that the exception is thrown after I have exited my code and it is back on the main thread of the application. The ClientRectagle is 609, 533. What else can I try?

Do the scrollbars work correctly before this exception? In fact, does everything seem to be just fine before the user adds this node that somehow causes this exception?

Are there any overrides of GoObject.Paint, or of Control.OnPaint, or is there a Control.Paint event handler?
If you change the GoView.BorderStyle to BorderStyle.Fixed, do you get that exception?
Can you tell if there is an unusual amount of resources being allocated?
  1. Everything appears to be working fine before the exception. What the scenario is: Add a new GoViewNode and then redraw. Add a second GoViewNode and then redraw. After I exit my code it throws this exception.
2. No overrides of any Paint
3. Fixed border still throws that exception
4. Nothing unusual in the resources being allocated.
5. Works with 2.6.1.2, but not 2.4

By “Add a new GoViewNode and then redraw”, what are you doing to redraw? You shouldn’t have to do anything – the view will update automatically as soon as that thread gets a chance.
In your last point, are you saying the same application works correctly using 2.6.1.2 but has an exception when using 2.4.1.x?

Yes the same application works for 2.6.1.2 by not for 2.4.1.x, unfortunately this is a sustaining defect for a product that we can not go back and bring up to 2.6.1.2 so we need to fix it for 2.4.1.x

The view does update itself, I was not clear in my description. This error occurs when we save out the Goview to our database and then recreate the GoView out of our database.. Because of a memory leak with Goview the code looks like:
goView1.Document.Clear();
goView1 = null;
goView1 = new LANDesk.Workflow.Win.controls.NRGoView();
this.splitContainer1.Panel1.Controls.Add(this.goView1);
goView1.AllowCopy = false;
goView1.AllowDragOut = false;
goView1.AllowEdit = false;
goView1.AllowKey = false;
goView1.AllowMove = true;
goView1.AllowReshape = false;
goView1.AllowResize = false;
goView1.ArrowMoveLarge = 10F;
goView1.ArrowMoveSmall = 1F;
goView1.BackColor = System.Drawing.Color.White;
goView1.Border3DStyle = Border3DStyle.Flat;
goView1.BorderStyle = BorderStyle.None;
WDToolbarsManager.SetContextMenuUltra(this.goView1, "DesignerMenu");
System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(frmWorkflowDesign));
resources.ApplyResources(this.goView1, "goView1");
goView1.ImageList = this.imageList2;
goView1.Name = "goView1";
goView1.DragDrop += new System.Windows.Forms.DragEventHandler(this.goView1_DragDrop);
goView1.MouseUp += new System.Windows.Forms.MouseEventHandler(this.goView1_MouseUp);
goView1.ObjectEdited += new Northwoods.Go.GoSelectionEventHandler(this.goView1_ObjectEdited);
goView1.DragEnter += new System.Windows.Forms.DragEventHandler(this.goView1_DragEnter);
goView1.LinkCreated += new Northwoods.Go.GoSelectionEventHandler(this.goView1_LinkCreated);
goView1.ObjectSingleClicked += new Northwoods.Go.GoObjectEventHandler(this.goView1_ObjectSingleClicked);
goView1.ExternalObjectsDropped += new Northwoods.Go.GoInputEventHandler(this.goView1_ExternalObjectsDropped);
goView1.SelectionDeleting += new System.ComponentModel.CancelEventHandler(this.goView1_SelectionDeleting);
goView1.KeyUp += new System.Windows.Forms.KeyEventHandler(this.goView1_KeyUp);
goView1.ObjectDoubleClicked += new Northwoods.Go.GoObjectEventHandler(this.goView1_ObjectDoubleClicked);
goView1.SheetStyle = GoViewSheetStyle.Sheet;
goView1.Document.DefaultLayer.AllowView = true;
goView1.InitializeLayersFromDocument();
LoadWorkflow(); //our code

The painting code in GoView hasn’t changed since 2.4.1 (or earlier, actually), other than adding support for two new properties: CompositingQuality and PixelOffsetMode, which shouldn’t really matter here.
What memory leak are you talking about? I’m not aware of any. Although your code might potentially have such a leak, if it holds anywhere to the old GoDocument or any part of it, since that would keep a reference to the old GoView. And you do remove the old GoView from your panel’s collection of Controls, don’t you?
It’s actually pretty common to just replace the GoView.Document with a completely new document, rather than trying to reinitialize a new GoView.

We do remove the old goview from your panel’s collection of controls. What else you suggest trying?

Did you try just deleting all that code, and doing this instead:

goView1.Document = goView1.CreateDocument();
LoadWorkflow();

I had done that earlier, but it still has the same exception

My current guess is that the exception is happening because that GoView isn’t part of your Form any more. Maybe it’s (partly?) disposed? Can you check that the GoView that is raising the exception is really the one that you have in your Form?
If you can remove all assignments of goView1, except the very first one when the Form is initialized, and all adds/removes of the goView1 from any Controls collection, except for the one when the Form is initialized, that would help narrow down possible problems.
Also, you say that this only happens after the document has been reloaded. Is that right? Might there be a problem with the implementation of LoadWorkflow(), assuming that it was called once before? Does LoadWorkflow modify any Controls or any system Pens or Brushes?