AutoCAD Profiles

What is a Profile?

An AutoCAD "profile" is a named collection of configuration settings.  A Profile may include options that control display, modeling, user interaction, printing and plotting, saving, importing and exporting, units of measurement, and so on.  There are essentially two types of "Preferences" in the AutoCAD environment: Application and Database.  "Database" is another word for "Drawing" in this context, so "Database Preferences" translates into "Drawing Preferences" or configuration settings that are drawing level or drawing-specific.

How are they stored?

They are actually stored as Windows Registry keys under the path: HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R18.2\ACAD-A001:409\Profiles\

The first profile created by default is the "<<Unnamed Profile>>" but as you create new profiles they will be added under the \Profiles\ path as well.

How are Profiles accessed and controlled?

There are several ways to get at profiles.

• From the OPTIONS dialog forms within AutoCAD
• From the Windows Registry
• From exported .ARG files
• From programmatic interfaces like COM and .NET

The first method is pretty simple and self-explanatory. So let's dig into the others.

The Windows Registry is where profiles are stored and maintained.  When you create a new Profile within the OPTIONS dialog, it creates a new sub-tree with the corresponding name and populates it with all the pertinent keys and values to store the profile configuration.

If you export the profile from within the OPTIONS dialog, it creates an .ARG file.  This is actually a .REG file (a Windows Registry export file format), so you can very easily rename a .ARG to .REG and use it like any other Registry data file (import, export, archive, etc.)

The programmatic interfaces for accessing and manipulating profile data are most often via .NET or the older COM interfaces.  Because they are stored in the Windows Registry, ANY other programmatic interfaces that can manipulate the registry can be used as well.  When it comes to leveraging .NET interfaces, you can pretty much narrow that down to Visual Studio tools like VB.NET, C#.NET, PowerShell, as well as ObjectARX®   When it comes to COM interfaces, you can use anything that talks COM.  Some examples include VBscript, Javascript, KiXtart, PowerShell.

Programmatic Access to Preferences

VB.NET

Dim acPrefComObj As AcadPreferences = Application.Preferences

C#

AcadPreferences acPrefComObj = (AcadPreferences)Application.Preferences;

VBA

Dim acadPref As AcadPreferences
Set acadPref = ThisDrawing.Application.Preferences

Visual LISP

(setq objAcad (vlax-get-acad-object))
(setq objAcadPrefs (vla-get-Preferences objAcad))

Windows Scripting Host - VBScript

Because VBScript is external to the AutoCAD application environment, it must first obtain an object instance of the AcadApplication class in order to begin drilling into the internal objects, properties, methods and so on.

Dim objAcad, objAcadPrefs
Set objAcad = CreateObject("AutoCAD.Application")
Set objAcadPrefs = objAcad.Preferences

Programmatic Access to Profiles

VB.NET

Dim acadApp As AcadApplication = CType(Application.AcadApplication, AcadApplication)
acadApp.Preferences.Profiles.ExportProfile("PROFILE_NAME", "C:\test.arg")

This is one way to get at Profiles from within an AutoCAD session environment.

Visual LISP

This is (or these are) another example of getting at Profiles from within AutoCAD.

example: linear expression…

(setq objActProfile (vla-get-ActiveProfile (vla-get-Profiles (vla-get-Preferences (vlax-get-Acad-Object)))))

example: unfactored collection of expressions

(setq objAcadApp (vlax-get-Acad-Object))
(setq objAcadPrefs (vla-get-Preferences objAcad))
(setq objProfiles (vla-get-Profiles objAcadPrefs))
(setq objActProfile (vla-get-ActiveProfile objProfiles))
(vla-ExportProfile objProfiles "Fubar" "c:\fubar.arg")

Windows Scripting Host - VBScript

This is an example of getting at profiles from outside of AutoCAD.

The downside to accessing the Profile collection via a non-object interface is that you don't get the nice object-oriented methods and syntax that make it kind of neat-o to use.  So instead of crawling the object tree, as it were, you have to fetch each entity as a distinct data value.

setq objShell = CreateObject("Wscript.Shell")
path = objShell.RegRead("HKCU\Software\Autodesk\AutoCAD\R18.2\ACAD-A001:409\Profiles\MyProfile\ACAD")
For each folderName in Split(path, ";")
    wscript.echo folderName
Next

Keep in mind that the Wscript.Shell RegRead() method is only useful on the local computer.  But this isn't really an obstacle since you don't really want to access HKCU on a remote computer (you have to first map the user SID to obtain the HKEY_USERS path because HKCU is a pseudo registry hive that exists only under the local user context).  So… you can do it, but you have to ask yourself if it's really the best approach to getting at things on a remote computer.  Why not invoke the interface under the local user context?

PowerShell

$a = get-item HKCU:\Software\Autodesk\AutoCAD\R18.2\ACAD-A001:409\Profiles
$a.SubKeyCount <-- returns the number of profile trees beneath the Profiles path
$a.GetSubKeyNames() <-- enumerates the profile names

The upside to using PowerShell over VBscript is that you can invoke object programming techniques.  This is because $a (in this example) is actually an object instance.  There are other ways to employ PowerShell, so don't think this is the only possible approach (it's barely scratching the surface).

Group Policy Preferences

That's right.  As astounding as it may be, I have long ago recommended Windows admins explore the use of Group Policy Preferences for managing and manipulating computer settings with less effort than scripting typically requires.

But you say "Dave?! How can you suggest we leave scripting out in the cold, starving and dying of neglect?!  How cruel!"

Fair enough.  But once you see how easy it is to create, modify and delete registry keys and values on a bazillion computers, you will look at your old login and startup scripts like the old girlfriend you dumped years ago (and never regretted).

Possibilities

They are almost endless.  For example, using the available tools and technologies, you can rig up a way to automatically reset profiles for classroom settings (if you don't use virtual machines to handle state management).  You can deploy and update a standard profile for specific business groups, locations or for the entire operation.  If a path reference is set in a default profile, but later needs to be changed (and you didn't map it to a DFS target) you can push out a fix using scripts or even a Windows Group Policy Preferences object setting.

Conclusion / Summary / Mumbo-Jumbo Ay Carumbo!

I have no intention of trying to create an ebook expose to exhause every conceivable way you can get at Profiles, create, rename, modify, delete, import or export them.  I also did not intend to cover every programming language or programmatic option available or possible.  The goal here is to simply show the following:

1. The Preferences and Profiles items are structured and fairly well-defined
2. They are accessible from a lot of different angles using a lot of different tools
3. You have choices and options at your disposal

That said: go forth and hack away.  Just don't call me if you break anything.