As I have mentioned in previous posts I am a fan of using the mnl as an access point to all custom AutoCAD menu content. Another popular method (which I avoid) is to place menu loading calls in the acaddoc.lsp file. My philosophy is to minimize modifying out of the box AutoCAD files and keeping as much custom content separated from delivered AutoCAD files as possible. This helps for a few reasons: one, upgrades are easier and smoother if all of your custom content is separate from the delivered AutoCAD files and can simply be reintroduced to the next version of AutoCAD. Another benefit is setting up a machine for a user is quick and easy and can be done by IT support in many cases (since out of the box AutoCAD is all that is needed and custom content can be introduced simply by adding a desktop shortcut that points to an arg file). Thirdly, this method keeps your menu sets organized so if you have multiple menu sets and AutoCAD user profiles they won't be conflicting with each other.
As with several areas in the AutoCAD realm, there is not necessarily a "right" or "wrong" way of doing something but rather an "optimized" way for each particular environment. The environment I work in includes multiple sets of standards for different clients and different third party applications so it is essential to keep my custom AutoCAD menu content organized.
Here is a flow diagram that represents an architecture that allows me to manage multiple environments for different clients and/or disciplines and keeps the custom content separate from AutoCAD:
This is a high level architecture but provides the framework for adding as much custom content as your heart desires...or rather, your clients/customers/users desire. We will look at the specific CUI architecture in a future post and talk about managing 3rd party applications and multiple AutoCAD based user profiles.
