What's a Custom Object?1 Jan, 2003 By: Bill Kramer
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.
|Table 1. Essential Functions for a Custom Object|
|File I/O||set of functions for input and output of data from files; support for both DWG and DXF|
|Drawing||viewport and world drawing functions; regenerate the graphics|
|Snap||implementation of the object snap feature|
|Grip||implementation of the grips feature|
|Stretch||implementation of the stretch feature|
|Intersections||implementation of the intersection feature for other common objects|
|Explode||implementation of the explode feature|
|Geometry||endpoints and a host of other geometry functions|
So when you start with the root AutoCAD entity object, you should next ask what you need to do. Table 1 summarizes the essential function work involved. Some are quite easy to write while others will require a great deal of time to design and get functioning properly. There is a fair amount of work involved here. Each entry in Table 1 actually symbolizes a handful to a multitude of functions.
It is important to note that your functions are also manipulating your custom object or applying the rules for its manipulation. In other words, it can all get quite complicated and is a daunting task for the beginner.
But there are some significant advantages to implementing custom objects when the application calls for them. Perhaps the most important to many people is the ability to define proprietary objects. That is where you make objects that only your workstations can view or manipulate when the ARX code is available. Using objects of that nature prevents unauthorized use of drawings and can be used in a variety of creative ways. Intelligent object families require a lot of planning and foresight. You must anticipate all the possible permutations that might occur and make sure your programming will be able to adapt. But intelligent objects represent the greatest possible pay back in terms of investment in customization, especially when applied to the correctness, quality, and consistent clarity of drawings.
The key to customization is to reduce the amount of repetitious work required to define drawings from design data. The better the drawing and the design interface, the faster these two steps can be accomplished. Object customization allows the CAD system to get closer to the dream of a computer that actually can do some thinking. Imagine a door object that is fixed to a wall and can be moved dynamically up and down the wall to the corners, but not in a way that violates loading or other code requirements. Imagine a beam that checks whether it can carry a load as the load is placed on it. Imagine a bearing that knows its limits and can make suggestions for alternatives. It all starts with your imagination! And then we keep on programmin'.