MCAD API FEATURES

MCAD API FEATURES

This chapter discusses MCAD API features and benefits for third-party applications, object keys, and the MCAD API architecture. The Mechanical Desktop modules referred to in the items below include part modeling, assembly modeling, drawing management, etc.

Uniform Object Referencing

Users refer to application objects uniformly, regardless of which module creates and owns the referred object. This 11511q166l approach reduces the number of exported objects, allows tighter integration across modules, and is one of the technologies necessary for a unified API.

Unified API for All Modules

The MCAD API is unified across all Mechanical Desktop modules. The same interface allows users to interact with all currently offered Mechanical Desktop modulesand with new ones that might be released in the future. The unified interface has the following advantages:

Reduces the number of exported functions

Eliminates redundancies and inconsistencies in exporting similar functionality Mechanical Desktop modulesMakes the API easier to learn

Reduces the amount of system documentation required

Promotes development of applications that work uniformly across models from the different Mechanical Desktop modules

All Mechanical Desktop modules subscribe to the same API, so the breadth of third-party applications can be increased in an automatic, transparent manner without being recompiled by the third-party developer. Today, for example, Mechanical Desktop surface geometry cannot be constrained. The MCAD API offers methods that deal with geometrical constraints, but at this time these methods are effective only when the parametric part modeler owns the geometry. In the future, the Mechanical Desktop might support constrained surface geometry. If and when that happens, the calls in the API that handle constraints will be honored by the Desktop. Third-party applications that made use of these calls and used to work only on parametric solid models will automatically start to work on Mechanical Desktop surface models as well.

Powerful Geometric Abstraction

With the MCAD API geometry keys, developers refer to geometric objects uniformly, without concern for the details of how that geometry was created or is stored. For example, an application refers to a line in the same manner, regardless of whether that line is a first-class database entity, a linear edge of a solid, or even inferred from other objects. This mechanism greatly facilitates writing code that is simple and robust.

Support for Geometry Change Notification

Application developers can get active (immediate) and passive (upon request) notifications of changes affecting any geometry used by any Mechanical Desktop module. Developers can use the type of notification that best fits their application needs. The two forms of notification can also be mixed and matched without limitations.

Referential Integrity Across Parametric Regenerations

Any reference to a Mechanical Desktop part entity remains valid across parametric regenerations (if a mapping exists from the entity in the model before regeneration to some entity in the new model). The system takes care of managing the mapping. With this capability, sophisticated applications can be written that are associative to the underlying model and make full use of the benefits of parametric, feature-based solid modeling. For example cutter paths or loads can be associated to faces in the model, and such relationships remain valid across model edits.

Attribute Support

The MCAD API supports attribute creation, customization, attachment, query, and edits. In addition, attributes that are attached to entities in a parametric model remain attached across parametric regenerations even though the actual model entity is deleted and recreated in the process. This functionality is very important for a variety of applications that need to attach attributes to parts of the underlying model. Custom attribute classes can be created and managed using the MCAD API.

Synergistic Integration with Other Autodesk APIs

The MCAD API makes use of other Autodesk APIs to enhance and facilitate third-party application interaction with the underlying model. The Geometry Library provides surface and curve modeling information and functionality. The B-rep API allows topological information to be obtained, and ObjectARX handles database, graphics, and user interface issues.

The MCAD API focuses on those aspects that are specific to mechanical applications, and relies on the other APIs for the additional functionality required by third-party applications. As more functionality is added to the other Autodesk APIs, users of the MCAD API benefit automatically.

Support for Asynchronous Releases of All Components

The MCAD API application and the different Mechanical Desktop modulescan be released asynchronously without forcing recompilation of existing third party applications. The third party applications might immediately benefit from some of the new enhancements without having to recompile. Other new features that would require code changes or recompilation can be taken advantage of at a later time.

This gives a lot of flexibility to third-party developers in terms of coordinating their enhancements with new releases of the MCAD API and of Mechanical Desktop modules.

Utilities for ObjectARX

The MCAD API provides utilities that enhance capabilities, such as picking and highlighting, that traditionally have been hard to use in the context of ObjectARX. The developer is not required to deal with and traverse low-level data structures if that level of flexibility is not required. Users can concentrate more on their application problems and less on peripheral issues.

Mechanical Desktop Part and Surface Modeling

The modeling power and sophistication formerly offered by the Mechanical Desktop, such as feature and constraint handling or complex surface modeling capabilities, are made directly available to third-party developers with the MCAD API.

Object Keys

Third-party applications use keys to refer to application objects. Keys are persistent and uniform across applications. All the necessary information to resolve the key to the referred application object is stored in the key. An application identifier that allows the system to quickly identify which application manages the key is also stored in the key. When a key is passed to an MCAD API function, the system knows what application created the key, so it can route the call to the proper piece of code.

Keys are C++ objects grouped in a terse hierarchy that provides users with type checking and hierarchical characterization. Because the MCAD API uses a functional interface to export functionality, methods are not present in the object key hierarchy. Keys are passed and returned as arguments of API functions. This approach insulates users from changes in the MCAD API implementations that might cause applications to break. The functions fully use the key hierarchical characterization, so that at compile time inappropriate key types cannot be passed into the function.

Object Key Hierarchy

The following key classes are defined by the MCAD API:

A polyline with a vector associated with each vertex

API users do not need to be concerned with the internal information stored in the key, what application created it, or how to handle the key. API functions construct a key, check if a key is null, save and restore a key, and release the key. The following paradigm is normally followed by the MCAD API user in working with keys:

Obtain an object key to a mechanical application object by calling appropriate API functions.

Use the key to identify the object when calling functions in the MCAD API.

Check the status returned by functions.

Save or restore the key if necessary.

Release the key when it is no longer needed.

Using the MCAD API Referencing Mechanism

The MCAD API provides a persistent, uniform referencing mechanism. This mechanism allows application developers to refer to objects in models without having to account for the details of which application created the object being referred to or the particular representation details for that object (e.g., whether the object being referred to is a first class database entity, is inside a block reference, is a subentity inside another object, or is inferred from other existing objects). An application refers to an application object by holding onto a key to the object. Keys to application objects are created at the third party developer's request.

Currently, in addition to geometric keys, keys to Mechanical Desktop parts, parameters, assembly constraints, components, component definitions, scenes, sketches, and features, drawing views, drawing annotations, as well as AutoCAD solids, are supported. The geometric coverage available encompasses the following types of geometric entities:

AutoCAD points

AutoCAD lines

AutoCAD arcs

AutoCAD circles

AutoCAD ellipses

AutoCAD splines

AutoCAD Polylines ( 2D or 3D) except non-simple polylines

Any vertex on a Mechanical Desktop part or surface, or an AutoCAD solid, body, or region

Any edge on a Mechanical Desktop part or surface, or an AutoCAD solid, body, or region

Any face on a Mechanical Desktop part or an AutoCAD solid or body

Mechanical Desktop surfaces

Mechanical Desktop augmented lines

Mechanical Desktop workpoints, workaxis, and workplanes

In addition to these direct references, the following inferences, on top of these references, are also supported:

Point as the endpoint of an open curve

Point as the midpoint of a linear segment

Point as the center point of a circle, circular arc, or ellipse

Line as the center axis of a circle or circular arc

Plane as the plane of a circle or circular arc

Summary

The following points highlight some key features of the MCAD API architecture:

The MCAD API is based on a flexible architecture that is designed to be extensible.

Object keys are used in most interactions between the client application and the MCAD API.

Most API functions delegate processing to different Mechanical Desktop modules such as part, assembly or surface API implementation modules.

The MCAD API uses information in the object keys to determine how to delegate the processing.

Some API functions, such as the selection and highlighting utilities, interface directly with AutoCAD.

The modular design allows Autodesk to ship updates of the API modules as well as the Mechanical Desktop without affecting released 3^rd party applications.

Future Mechanical Desktop modulescan be easily integrated into the existing MCAD API architecture. Existing client applications of the MCAD API are automatically supported by the new Mechanical Desktop modules