Developer Partner Guidelines
The following information is excerpted from Autodesk Mechanical Solutions Developer Partner Guidelines Revision 1.0, dated June 26, 1997.
Introduction
Autodesk Mechanical product acceptance and quality are measured by customer perception of not only Autodesk products, but of developer partner products as well. This document presents a set of guidelines and certification requirements to assist our developer partners in their responsibility to deliver high-quality products that integrate well into Autodesk Mechanical products. These guidelines, available to all developer partners, lay the foundation for certification, which allows developer partners to brand their products with a badge symbolizing Autodesk Mec 23123h714x hanical product integration and interoperability.
Part 1 outlines the "Product Development Guidelines" that ensure developer partner products work well with the current Mechanical Desktop and AutoCAD Mechanical and with other Autodesk products in the future. Developer partners must follow these guidelines to have their products certified by Autodesk.
Part 2 provides the "Installation Development Guidelines" for developer partners who use the MCAD API in their products.
Autodesk recognizes that each developer partner product is unique in its target market, technical complexity, interaction with the Mechanical Desktop, and packaging. This document, which will change over time with product evolution, is a guideline for all of these products. As new requirements are identified, they will be incorporated into future versions of this document.
If you have any questions about whether your product(s) meet these requirements, contact your standard registered developer support channel.
Part 1
Product Development Guidelines
These guidelines, available to all developer partners, must be followed by those who wish to have their products certified by Autodesk. The guidelines ensure that developer partner products work well with the current Mechanical Desktop, AutoCAD Mechanical, and with other Autodesk mechanical products in the future.
1. Follow All ObjectARX Developer Guidelines
Meaning All Autodesk issued guidelines for development of ObjectARX applications, which are included in the ADN CD collection, must be followed. When a certification process is put in place for ObjectARX applications, all the requirements for that process must be satisfied.
Motivation Your application is an ObjectARX application. Thus, you must follow all basic ObjectARX guidelines as well as all developer partner development and certification guidelines to ensure integration into our environment.
Considerations Autodesk provides extensive documentation, training, and email support to enable developers to achieve this goal.
2. Be Compatible with Autodesk Mechanical Solutions and Other Partner Applications
Meaning Your application should not conflict in any way with the Autodesk Mechanical solutions or with other partner applications. This includes, but is not limited to, installation, de-installation, database coexistence, loading and unloading of files, handling of menus and help files, ability to go back and forth between Autodesk Mechanical solutions and partner applications, and opening of files containing objects created by your application when your application is not present. Applications should have capability to load and unload during an Autodesk Mechanical solution session, allowing the user to control overall memory usage.
Motivation End users want to be able to mix and match different developer partner applications with the Autodesk Mechanical solutions.
Considerations Many of the issues raised here are addressed by the use of commonly known, good programming practices. If you have access to other developer partner applications for the Mechanical Desktop, test your application with these products.
3. Have a Consistent End User Paradigm
Meaning Design your application to look and feel like a natural extension of AutoCAD and the Autodesk mechanical solutions and to be Windows compliant.
Motivation Users want to have seamless integration without drastic paradigm changes as they use AutoCAD, the Autodesk mechanical solutions and developer partner applications.
Considerations In some cases it might make sense to deviate from the established paradigm to enable new functionality or facilitate a task, but this should be the exception rather than the rule and needs to be justified.
4. Use AutoCAD Tools
Meaning Your product should use, as much as possible, tools that are native to the AutoCAD environment. This includes, but is not limited to, utilizing the standard mechanisms for graphics display, manipulation, picking/grips, and highlighting; file handling; entity copy, delete, move, rotate, mirror and scale; grouping and blocking; and rendering, if appropriate. If some of these standard AutoCAD operations are not applicable, it is your responsibility to react to operations accordingly. Note that the use of MFC tools is also encouraged.
Motivation End users want to continue using familiar AutoCAD interactions whenever possible.
Considerations By having your application objects derive from AcDbObject and AcDbEntity, and by implementing the appropriate virtual methods, many AutoCAD native commands automatically work on your entities.
5. Have Complete Geometric Coverage
Meaning Operations that involve geometry should work on all applicable types, including all types of curves and surfaces, geometry that is wireframe, Mechanical Desktop surfaces, a solid, a parametric part, an assembly component, inside block references, and external databases. If an operation is appropriate only for a particular geometry type, the user interface should trap the condition and clearly notify the user.
Motivation Users do not want their applications to work for only certain geometric configurations.
Considerations Full geometric coverage is easily accomplished through the use of the geometric keys provided by the MCAD API. By using these keys, developers are automatically relieved of dealing with the underlying details of the type(s) of geometry that are members of composite entities such as polylines, blocks, or groups; inferred geometry such as end points, mid points, center points, axes, or planes; and geometry that is externally referenced from other files.
6. Extract All Model Information
Meaning Information that is already present in an Autodesk Mechanical solution model should be extracted automatically by applications that need it. Users should not have to re-enter common attribute information, such as material properties. Other, higher level examples would be that assembly constraints can be extracted automatically from the model and used in defining joints for a kinematics application, loads calculated by kinematics applications can be used by FEA applications, and that design parameters can be used for shape optimization in a CAE or mold flow application.
Motivation Users do not want to spend time reentering information that was previously specified to the system.
Considerations A developer who believes that it is not possible to access the required information should contact Autodesk to remedy the problem.
7. Be Associative
Meaning All your application objects which are related to objects in an Autodesk mechanical solution model should have the ability to update themselves in response to changes in the Autodesk Mechanical solution model.
Motivation Users expect applications to be intelligent in their association to the underlying model across edits to the model.
Considerations The MCAD API provides a variety of tools that make it straightforward for developers to write associative applications in a variety of flavors to fit different application paradigms. By retaining MCAD API keys, an application can update geometric and other entities across model regenerations, add attributes that are associative, and get active and passive notification of changes.
8. Use Standard Attributes and Objects
Meaning Sharing of higher level information requires the use of persistent, sharable attributes created by developer partners. Developer partners should use, whenever applicable, standard attributes, MCAD API instantiable attributes, objects defined by the MCAD API, and additional attribute data defined by developer partner applications instead of defining their own versions. If an application creates objects which have a natural representation within the Mechanical Desktop, that representation should be used. For example, solids should be represented using parts; assembly structures should be made as Mechanical Desktop assemblies.
Motivation The use of commonly defined objects promotes interoperability across different applications. In addition, a standard attribute that is attached by one application can be operated upon by another application, even when the application that planted the attribute is not loaded.
Considerations The instantiable attributes mechanism provided by the MCAD API in combination with standard attribute definitions provide a convenient way for applications to deal with attributes without the burden of having to write supporting code for the classes involved.
9. Use DWG File to Store All Model Data
Meaning Have all the data that defines your model saved with the DWG file format instead of using additional files to save part of the model definition.
Motivation This approach avoids complications when users exchange data. It facilitates support for several operations involving database manipulation (such as undo/redo operations).
Considerations Large data sets could represent an exception to this rule. Examples would be derived NC tool paths, and FEA results. In applications that have large data sets, the user should be able to store the file without this data if so desired.
10. Support Undo/Redo
Meaning All your application objects should fully support undo and redo operations as presented by AutoCAD.
Motivation Users have come to expect this, and it is a key feature of our environment.
Considerations This can be accomplished by following the ObjectARX development guidelines concerning implementation of the appropriate dwgin/out methods for all application classes.
11. Have a High Level of Quality Assurance
Meaning The development of your application should be done in a context of high concern for overall quality.
Motivation The development environment that ObjectARX/MCAD APIs provide is very powerful and complex. Quality problems in your application have the potential to impact other applications as well. Users expect the highest standards of quality from suites of partner applications.
Considerations This is, in a way, an obvious point, but it should not be taken for granted.
12. Support Globalization
Meaning Your application should be localization ready for all the markets where Autodesk mechanical products are sold. The ObjectARX developer guidelines provide information on how to structure your application to achieve this.
Motivation Ours is a global market, and having the applications adapted to the different countries where they are sold is a key user requirement.
Considerations In order to have this process go smoothly, pay attention to globalization throughout the product development. Autodesk has available documentation, strategies, and training material to help developers support globalization in their products. This information can be obtained from your standard registered developer support channels.
13. Stay Current
Meaning Continue to update your application to account for enhancements made to AutoCAD, the Autodesk mechanical solutions, the MCAD APIs, and to common object definitions. The developer partner is responsible for validating the compatibility of its products with all new versions of Autodesk mechanical solutions and the MCAD API that are made available to developers.
Motivation As we continue to make improvements in Autodesk mechanical products it is in the best interest of everyone that these enhancements be reflected in additional functionality in your products. It is also important that all applications are available as soon as possible after a revision of the Mechanical Desktop is available.
Considerations We plan to enhance the Autodesk mechanical products and APIs on an ongoing basis and to keep developers informed of these advances. Many of our future enhancements will originate from requests and feedback from developer partners and developers in general. ObjectARX and especially the MCAD API provide upward compatibility between Autodesk Mechanical solutions revisions, allowing developer partners to rapidly validate support for new revisions.
14. Pursue Interoperability with Other Partner Applications
Meaning Strive to have your application work synergistically with other certified developer partner applications.
Motivation End users experience great benefit from suites of applications that work well together. For example, an analysis application could use forces calculated by a dynamics application as load conditions.
Considerations To achieve interoperability, partners should interact closely with each other. In addition, Autodesk will continue to promote and assist in these cooperation efforts.
Part 2
Installation Development Guidelines
These guidelines for the design of developer partner applications installations must be followed.
1. What Product to Use for Installation
The Autodesk Mechanical Desktop uses the InstallShield product for its installation. We recommend that developer partners do the same. More information can be found at the InstallShield web site at https://www.installshield.com.
2. Menu Changes
The Autodesk Mechanical Desktop uses a menu replacement method. Developer partners should use the Menuload option when they need to add items to a menu or to add a new pulldown. This will allow the addition of new pulldowns to a menu without editing menus added by the Mechanical Desktop or by other developer partner applications. For more details see chapter 4, "Custom Menus," in the AutoCAD Customization Guide.
3. The ACAD.RX and Loading of Applications
It is highly recommended that you consider using demand loading of your application instead of using the acad.rx. Refer to "Loading an ARX Application" in Chapter 3 of the ObjectARX Developer's Guide for information about demand loading.
4. Installation of Your Application in Its Own Directory
A developer partner application should install into its own directory off a root drive. To have your application run with the Mechanical Desktop, your installation will have to edit the acad.ini found in the mcad or equivalent directory to add your path to the acad path statement. This is needed to load your application when the Mechanical Desktop is loaded.
5. Look and Feel of Your Application Installation
The look and feel of a developer partner application installation should match that of the Mechanical Desktop. Using InstallShield automatically ensures this is done.
|
