Through the Interface: Examples of calling Dispose() on AutoCAD objects

May 2015

Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


« Calling Dispose() on AutoCAD objects | Main | Service Pack 1 for AutoCAD 2013 »

August 22, 2012

Examples of calling Dispose() on AutoCAD objects

To accompany the last post – which raised some questions around when and where to call Dispose() on objects created or accessed via AutoCAD’s .NET API – today we’re going to look at a few concrete examples.

Thanks to Danny P for not only requesting some examples but also presenting some concrete areas he wasn’t fully clear on. Let’s start by looking at those (and feel free to compare the responses I’ve put below with the ones I made in direct response to Danny’s original comment):

Within a transaction where something is added to the database, some new objects (Xrecords, dictionaries) can be relatively simple and might only need a Using block. Conversely, complex objects (dimension styles, block definitions with attributes) have many properties and resulting code with potential points of failure. How would you deal with that in a Try...Catch block + Using block to handle exceptions at the object level and the transaction level?

The short answer is that anything managed by a transaction – whether newly created and added to the transaction or opened by it – will be disposed of automatically by the transaction. So in general you shouldn’t even need a using block around such entities.

For more complex scenarios the same is also true, although if you’re creating a database-resident definition object, for instance, then you’d need to make sure that it also gets added to the transaction.

In the case where a new object is “owned” by another new, more complex object (such as a FontDescriptor being owned by a TextStyleTableRecord via its Font property), then you can generally assume that just by setting the property on the owner you’ve absolved yourself of needing to Dispose() of it yourself. The example I’ve used isn’t a great one, admittedly – FontDescriptors don’t actually require disposal – but hopefully you get the point I’m trying to make.

A second thing that I found was casting Entities to specific object types, for example iterating through block definitions looking for a line, and casting that Entity to a Line object. Do I need to dispose of the Line because I didn't use line = transaction.GetObject(...), but rather line = TryCast(entity, Line)? In other words, is the new object a "transaction-managed" object, or do I need to dispose of it, or is it not a new object to the database and I don't need to worry about it?

This is an interesting point. In this situation, the object reference in the Line variable is not actually created by the cast (your TryCast() call in VB.NET). It was created by the call to Transaction.GetObject(): all the cast does is attempt to coerce the reference into a variable of another type (after it has first checked that the reference object also support the Line protocol). The object reference between the Entity and Line variables are one and the same – with the same, underlying, unmanaged pointer – it’s just they’re conveniently held in variables of different types that allow compile time features such as Intellisense and static type checking (even if the TryCast() could conceivably fail at runtime, if the object didn’t happen to be a Line). So as long as the original object reference is managed by a transaction – and in this case you’ve received it from the transaction – then all is well.

Now let’s take a look at a couple of examples of where you might add calls to Dispose() in new code. I started by looking for previous posts with “theoretically” problematic code, and found this one.

Here’s the code in question:

      // Create the mirror line and the transformation matrix


      Line3d ml = new Line3d(pt1, pt2);


      MirrorEntity(doc.Database, per.ObjectId, ml, false);

Basically we’re not calling Dispose() on the temporary Line3d object after the MirrorEntity() method has completed. We could simply adjust the code as follows to have the Line3d get disposed at the end of the using block:

      // Create the mirror line and the transformation matrix


      using (Line3d ml = new Line3d(pt1, pt2))


        MirrorEntity(doc.Database, per.ObjectId, ml, false);


Again, this is not a change that you absolutely need to go back and perform in your code – I have every expectation that this code will continue working properly in future versions of AutoCAD without Line3d being disposed of – but we’re really talking about avoiding problems that are theoretically possible.

Now let’s take a look at code in another post that uses the potentially problematic Brep API identified in the last post. (Both the examples I’ve linked to happen to have been provided by other people – that’s honestly not a deliberate choice, they just happen to have been the ones I found that best demonstrate the issue. :-)

When I ran this code again from the debugger, stepped through it and then closed AutoCAD, I actually did receive an exception that seems related to this issue:

Brep API exception

It’s possible this isn’t due to this problem – which is by its nature intermittent and tricky to catch – but the fact it’s in the destructor of an AcGe object seems a giant red flag.

Here’s a revamped version of the C# code. I ended up going a bit crazy on introducing the use of var instead of specific types (although you shouldn’t worry – this code is still perfectly typesafe as all types are inferred at design time), which hopefully doesn’t distract you from the more important changes (which were to introduce a manual Dispose() and a number of using blocks).

using Autodesk.AutoCAD.ApplicationServices;

using Autodesk.AutoCAD.BoundaryRepresentation;

using AcBr = Autodesk.AutoCAD.BoundaryRepresentation;

using Autodesk.AutoCAD.Colors;

using Autodesk.AutoCAD.DatabaseServices;

using Autodesk.AutoCAD.EditorInput;

using Autodesk.AutoCAD.Geometry;

using AcGe = Autodesk.AutoCAD.Geometry;

using Autodesk.AutoCAD.Runtime;

using System.Collections.Generic;

using System;


// Not mandatory, but improves loading performance


[assembly: CommandClass(typeof(HoleFeature.MyCommands))]


namespace HoleFeature


  public class MyCommands



    public void GetHoles()


      var doc = Application.DocumentManager.MdiActiveDocument;

      var db = doc.Database;

      var ed = doc.Editor;


      var peo = new PromptEntityOptions("\nSelect a 3D solid: ");

      peo.SetRejectMessage("\nMust be a 3D solid.");

      peo.AddAllowedClass(typeof(Solid3d), true);


      var per = ed.GetEntity(peo);


      if (per.Status != PromptStatus.OK)



      var tr = db.TransactionManager.StartTransaction();

      using (tr)


        var solid =

          tr.GetObject(per.ObjectId, OpenMode.ForWrite) as Solid3d;


        var ids = new ObjectId[] { solid.ObjectId };


        var path =

          new FullSubentityPath(


            new SubentityId(SubentityType.Null, IntPtr.Zero)



        // For storing SubentityIds of cylinderical faces


        var subentIds = new List<SubentityId>();


        using (var brep = new Brep(path))


          foreach (var face in brep.Faces)


            using (var surf = face.Surface)


              var ebSurf = surf as ExternalBoundedSurface;


              // We are only looking only cylinders


              if (ebSurf != null && ebSurf.IsCylinder)


                var cyl = ebSurf.BaseSurface as Cylinder;


                // And fully closed cylinders


                if (cyl != null && cyl.IsClosed())


                  // Get normal and point on surface


                  var normal = new Vector3d();

                  var pt = new Point3d();


                  GetNormalAndPoint(surf, ref normal, ref pt);


                  if (IsHole(face, normal, pt, cyl))











        // Assign red color to hole features


        if (subentIds.Count > 0)


          short colorIdx = 1;

          AssignColor(solid, subentIds, colorIdx);







    // Get normal and point at mid U and V parameters


    void GetNormalAndPoint(

      AcGe.Surface surf, ref Vector3d normal, ref Point3d pt



      var box = surf.GetEnvelope();

      double p1 = box[0].LowerBound + box[0].Length / 2.0;

      double p2 = box[1].LowerBound + box[1].Length / 2.0;

      var ptParams = new Point2d(p1, p2);

      var pos = new PointOnSurface(surf, ptParams);

      normal = pos.GetNormal(ptParams);

      pt = pos.GetPoint(ptParams);



    // A cylinder is a hole if the normal points inwards

    // and the normal after extending by radius intersects

    // with axis of symmetry, the axis of symmetry is also

    // extended by height of cylinder


    Boolean IsHole(

      AcBr.Face face, Vector3d normal, Point3d pt, Cylinder cyl



      if (!face.IsOrientToSurface)


        // Correct the normal and save back


        normal = normal.Negate();



      // Calculate another point on normal by extending the

      // normal by radius of cylinder


      var opt =

        new Point3d(

          pt.X + normal.X * cyl.Radius,

          pt.Y + normal.Y * cyl.Radius,

          pt.Z + normal.Z * cyl.Radius



      // Get the cylinder's axis


      var v1 = cyl.AxisOfSymmetry;


      double dist = cyl.Height.Length;


      // Calculate another point on axis by extending v1 by dist


      var pt2 =

        new Point3d(

          cyl.Origin.X + v1.X * dist,

          cyl.Origin.Y + v1.Y * dist,

          cyl.Origin.Z + v1.Z * dist



      // Create line segment representing the cylinder's normal

      // Create line segment representing the cylinder's axis


      Point3d[] intpt = null;


      using (var ls1 = new LineSegment3d(pt, opt))

      using (var ls2 = new LineSegment3d(cyl.Origin, pt2))


        // Get intersection of normal and cylinder axis


        intpt = ls1.IntersectWith(ls2);



      return (intpt != null);



    // Assign color to cylinderical surfaces which are holes   


    void AssignColor(

      Solid3d solid, List<SubentityId> subentIds, short idx



      foreach (SubentityId subentId in subentIds)


        var col = Color.FromColorIndex(ColorMethod.ByColor, idx);

        solid.SetSubentityColor(subentId, col);





One thing that’s a little peculiar with the Brep API is that you’re actually forcing a Dispose() on objects that are properties of the Brep object itself (objects that are instantiated when you access the property). That doesn’t always seem right – you would expect the using block around the Brep object to force a Dispose() on all associated objects created/exposed via its properties – but this a quirk of the Brep API that needs special attention, and a big reason the GC-driven finalisation of unmanaged objects seems to rear its ugly head more often when it’s used.

The good news is that the results of over-aggressive disposing – you should see some kind of exception at object disposal – are going to be obvious much more quickly than those of inadequate disposing, which will probably take some time to identity. So it’s generally better to dispose more often than perhaps strictly needed when using the Brep API, but to pay special attention to exceptions (if you blindly catch and ignore every exception that gets thrown, you may run the risk of missing such issues).

Hopefully looking at a few concrete examples has helped improve the understanding of this tricky area. Be sure to post a comment if you have follow-up questions regarding this topic.

blog comments powered by Disqus


10 Random Posts