What's a Custom Object?

In the world of AutoCAD programming it is not uncommon to hear someone mention the term custom object. Although this term sounds great and may have a mysterious connotation that makes you think it can solve everything, you need to be somewhat educated as to what is involved before embracing the concept too much. That is not to say that custom objects are a bad thing. No, they are wonderful when used right. But they can also be their own problem as they open the door to many potential pitfalls and programming nightmares that are not easy to anticipate and avoid as you venture into this new territory.

Let's start by leaning what an object is in terms of programming and then how the concept of an object is applied to applications such as AutoCAD. With that in mind, you can then begin to appreciate the reality of a custom object.

An object is a container holding both data and associated functions that manipulate the object. In programming terms an object contains properties (the data) as well as methods (the functions). The properties can be any of the valid data types such as integers, doubles, or strings; which makes sense to most of us right away. However, there can also be objects that are defined as data that may contain other functions and properties. This can get quite confusing for those not used to object-oriented programming concepts.

Conceptually we define a CAD system using object structures by starting with the most basic item, an entity object. Every entity object in the AutoCAD system, no matter what it is, has some basic properties in common such as the layer name, the color code, the linetype code, and so on. The methods associated with an entity object will be used to manipulate these common properties. So far this is pretty simple, but this is just the root. From the root grows the individual entity types such as LINE, ARC, and CIRCLE.

A line object has some properties and methods that are in common with a circle object. Each will have layer, color, and other data inherited from the common root entity object. But each also has properties that are unique to the essence of the item in question. For example, the circle will have the center point, radius, and area properties while the line will contain a pair of points. Not only are the properties somewhat different but the way the object is manipulated and used in AutoCAD differs. Consider what happens when you use the AutoCAD grip feature and modify either of these objects. For the circle, you may be modifying the radius, at which point the circle graphics are recreated; for the line, you may be changing one of the ending points, causing a new line graphic to be instantly generated. The behavior is similar but not exactly the same.

So what's a custom object? If you have lines, arcs, circles, and text, what more do you need? Turns out there are lots of great ideas for custom objects. There are some that require a lot of work to create and others that require less. It all depends on the object being considered and how it will interface with other objects. An example is a simple door object. It might only be programmed to draw the door outline given a set of parameters. Attribute data can be attached to the door, allowing for analysis or material extracts. At this point we are not much beyond a nice block library or parameter-driven utility function, but we are only at the beginning.

When the door object interfaces with the other objects in the drawing, things start to get interesting. To continue, doors are normally found in a wall. Thus, it would make sense to define a set of rules and procedures for how the door object interfaces with the wall object. These rules can be basic (break the wall lines at the door) or more advanced (do not allow the door to be too close to the corner). It can go further if we know more about the wall--for instance, whether it is an outside wall, load bearing, and so forth. Our rules can be expanded for the type of doors that each type of wall will accept and the limitations that may exist.

Sounds pretty exciting when you start to consider the endless possibilities of capturing intelligence of that nature in graphic objects you manipulate on a daily basis. So, now let us turn our attention back to the actual programming work that is involved.

When programmers discuss objects, they consider these three traits:

• Inheritance, which is where an object can pass on traits to other objects that are derived from it;
• Encapsulation, which is where an object is self-contained and does not interfere with other objects but knows how to react to changing circumstances;
• Polymorphism, which is where the same function or property names can be used with different objects.

I won't explore these traits here except to note that polymorphism and inheritance do play an important part in the actual work behind AutoCAD custom object programming.

When you create a new entity object, it inherits all the features of the parent object. For AutoCAD that means that your new object has an entity handle, a layer assignment, a color assignment, and so forth. Now it is up to you to define all the additional properties and activities that take place with that object.

A custom object needs to react just like any other AutoCAD entity object. That means it must respond to grip requests, object snap, regeneration, highlighting, and all those other aspects of an AutoCAD object a user takes for granted. And each of these reactions needs to be programmed.

It may seem tempting to simply inherit from an existing AutoCAD entity object. At first glance it seems that would take care of many of the basics. After all, if your object looks like a line, why not just use the basic line object as a foundation and grow from it? There are several good reasons not to do this.

The first reason is, you actually gain nothing. If your object is more than just a line, then you still need to define the various reaction functions that will be called when the object is manipulated. Autodesk does not supply the source code to the existing entity objects, so you are starting from the same place as if you started from the root AutoCAD entity object.

Another good reason not to inherit from the existing AutoCAD entity objects is, you are setting up a hierarchy other processes may have trouble following; that is, you are defining a system where there are two objects that are similar at the same level. To AutoCAD and other ARX programs, your custom object would appear as a standard object at first glance. And it may be manipulated as a simple object resulting in the loss of data from any custom properties you were using. You should expect programs that manipulate objects to be derived from the root AutoCAD entity object and, if they are not derived from it, expect them to behave erratically.