Autodesk User Group International

Because I support multiple AutoCAD versions, or vertical products, I frequently have the need to add and remove support file search paths as different routines, macros, and scripts are modified, replaced or added to the office standard.

In addition, in order to better support multiple office locations with differing drive letter designations, I required a method to standardize paths. I accomplished this need by creating a standardized path tool allowing customization routines to be loaded without being hard coded for different paths in different office locations. In order to simplify the effort and make it as portable and modular as possible, I long ago switched to a system of data files and registry keys to control this customization. I chose data files because they could be changed rapidly and modified on the fly as needed. They could also be edited easily with readily available tools. I could also create some common data files which could be utilized by VBA, AutoLISP, and Visual LISP. I will most likely rewrite this code when I switch the data files to XML format sometime in the future, but that is the stuff of another article.

I have created a system comprising a set of registry keys which can be quickly modified as needed. This system of registry entries holds the keys, no pun intended, to a few local folders and the standard set of network folders containing the bulk of the office standards and custom routines. I desired to create a system that could be:

Supported remotely
Installed automatically
Modified on the fly as needed

The final requirement for this system was that it must operate as an overlay on top of an "Out of the Box (OOTB)" installation of software without major intervention or creation of a custom install package. I covered this concept and provided example code during my "One Click Customization" class at AUGI CAD Camp 2004 in Jacksonville, Florida. I will continue this series of articles until all aspects of this system have been explored.

In order to be truly functional, this overlay had to be modular. To complete this system I had to utilize nearly all the different customization environments and languages that AutoCAD has available to it. So without further ado, let's begin by looking at the structure I created and utilize heavily by reading and writing to some new keys in the windows registry. See figure below.

As you can see, I have added a new registry key to the "Software" key under the HKEY_CURRENT_USER hive. This new key has two regular string type entries pointing to the main drives used to support user customization (F:\) and Office Standard customization (X:\) as well as three sub keys located within the root key.

The concept of providing modular and supportive customization to our users is made possible by a couple levels of customization. The first and most important is the Office Standard set of routines, standards, and content. It is designed to be dropped on top of a standard OOTB install of AutoCAD 2005. Because we only run vertical products, this system was configured to work with all three vertical Autodesk 2005 based products; Autodesk Architectural Desktop, Autodesk Building Systems, or Autodesk Land Development Desktop. Once the Office Standards are loaded and engaged, a further level of customization is made possible by loading an additional user-defined LISP and/or custom menu. This user LISP and/or custom menu is available to users for modification under their complete control.

Our users are taught how to perform manual, partial loads of custom menus, and are also provided with a basic LISP template file, user2005.lsp, containing boilerplate examples of AutoLISP macros and VBA loading mechanisms and macros. This LISP file and the available custom.mn* is automatically loaded for them. Users who do not have the inclination simply get an empty template file loaded. Those that are motivated to gather and use routines are able to modify these files at their leisure. They are free to add any additional routines they may have found, created, or borrowed from others to enrich their AutoCAD environment.

The following bullets identify the sub keys and values created under our new custom registry key, THC_CADD.

The first listed is the Net_Paths key (See figure right). This key contains multiple registry values designed to point different lisp and vba routines to specific files and folders based on company standards. These paths are used for locations like plot style tables, plotters, fonts, etc. Essentially any path that all users of this vertical application might need would be found here as well as some additional standard office folders containing borders, logos, etc.
The second key contains various settings related to custom routines to provide a more uniform and standardized setup. Things such as remembering placements for dialog boxes, sizes of those boxes, frequently used settings and phrases that make the user experience friendlier.
The last key contains the local customization paths and files. It was originally created to work around AutoCAD's VBA limitation on concurrent users of VBA macros and provided a way to update frequently used routines which might otherwise be locked out by a user when the macro is in use. (These files are automatically compared to master copies on the network and updated by a preconfigured acad.lsp file prior to their automatic load in each session of AutoCAD.)

The figure shows some of the registry entries that are available to all customization run under this system. Notice that some of these would ordinarily be found under the User Profile (C:\documents and settings\[username]...) such as the plot drivers, plot styles, and templates folders, but are now located on a network share that can be centralized and standardized for the entire staff. One of the primary benefits of this system is the ability to transparently move and migrate customization routines to new locations while the staff is running the software. This system of frequent checks provides an automatic redirect based on alternate data files without requiring user intervention. This allows the CAD manager to take hardware off line, update drivers or applications, and also allows a user to work locally, if so configured, in the event of server failure or maintenance. It also provides a mechanism to enable laptop users to run the full load of customization while traveling, without the necessity of hard coded paths and duplicate file stores on the local drive.

These registry entries shown in the figures are created, modified, and maintained by various AutoLISP, Visual LISP, VBA, and VBScript routines which all read the same basic data files as necessary to gather the settings as needed. The data file where these paths and key names reside could, and probably will, be re-written as an XML data source in the future but for now it is simply set up as a "pipe" delimited file that is entirely text based for ease of maintenance. The figure below shows a portion of this "dat" file, which displays the custom registry key and the value associated separated by a "vertical pipe" symbol.

As I mentioned in the last article, certain common files get automatically loaded by AutoCAD when found in the application's support file search path. We take full advantage of this fact by doing a little bit of recon inside of the registry, creating a vbscript to enable automatic installation, and ensuring that our path gets added to AutoCAD's support file search path. Since we know that if AutoCAD finds a file named "acad.lsp" it will automatically load it and run the commands and functions found with in it, we take full advantage of this automatic behavior by ensuring that AutoCAD can find a file of this name. All right, enough background, let's get coding.

The first thing that happens after an OOTB install is for someone to run a VBScript file that I will share with you now. This file could be scripted into the desktop shortcut by the person performing the install or the file can be run once and forgotten. In the following script file, you will find:

a method to read and write to the registry
a constant pointing to a particular application
frequent use of activex libraries including:

Let's get started; all code to be entered will be shown in a text box as in the following example under item number 2 below:

Launch your favorite text editor
Add the following constant declaration. This example uses Architectural Desktop, but you can use whatever you have. Just be sure to swap out the number sequences (R16.1 and/or 304:409) and replace them with the appropriate application identifiers. You will also wish to identify and modify the "profile" name that you wish AutoCAD to run.

Const c_ADT2005 = "Software\Autodesk\AutoCAD\R16.1\ACAD-304:409\Profiles\Architectural Desktop - Imperial\General"

Now let's declare some variant objects that we can populate. If you don't know what I'm talking about here, then you should spend some time reviewing basic VB/VBA syntax and methods. I wrote a series of 12 articles on getting started with VBA. They are available at the following link.

Dim d
Dim fso

Finally, we are ready to write our routine. We will populate and activate our variants declared above and call our workhorse function, which will follow.
```
Set fso = CreateObject("Scripting.FileSystemObject")
Set d = fso.GetDrive("X:")
If d.IsReady then
	'msgbox "X:\ is available"
	VerifySupportPaths d, c_ADT2005
End If
```
Note that we are using standard object creation methods such as the CreateObject syntax.

The following code is the workhorse of our initial routine. It contains its own declarations. I take advantage of the Windows Management Instrumentation (WMI) functionality to rip quickly through the registry. Note that the following code reads two entire hives from the registry during its run. Of course, we don't even use one of them and I would encourage you to remove the HKEY LOCAL MACHINE (HKLM) from the routine, but it is interesting to note how fast the routine runs even when it is included.

Function VerifySupportPaths(oDrv, strProduct)
   Dim strLetter
   strLetter = oDrv.DriveLetter & ":\"
   Dim arHives
   Set arHives = CreateObject("Scripting.Dictionary")
   arHives.Add "HKCU", &H80000001
   arHives.Add "HKLM", &H80000002 �comment this out
   'use WMI to connect to the registry
   Dim oReg
   Set oReg = GetObject("winmgmts:root\default:StdRegProv")
   Dim arValues, arType, oVal, strData, strD2, blnChk
   strRunKey = "Software\Autodesk\AutoCAD\R16.1"
   oReg.EnumValues arHives("HKCU"), strRunKey, arValues, arType
   oReg.GetStringValue arHives("HKCU"),c_ADT2005,"ACAD",strData
   If InStr(1, strData, "CAD2005\Custom", 1) > 0 then
      	blnChk = True
      Else
      	blnChk = False
   End If
   Dim arSplit
   If Not blnChk then
	   arSplit = Split(strData, ";", -1, vbTextCompare)
		for i = LBound(arSplit) to UBound(arSplit) - 1
			Select Case i
			    Case LBound(arSplit)
			    	strD2 = strLetter & "CAD2005\Custom"
			    Case Else
			    	strD2 = strD2 & ";" & arSplit(i)
			End Select
		Next
   Else
   	strD2 = strData
   End If
   oReg.SetStringValue arHives("HKCU"),c_ADT2005,"ACAD",strD2
   msgbox "All Done" & vbcrlf & "Please Restart AutoCAD"
End Function

This function accepts a drive object (d) and a predefined constant that points the function to the correct application/profile for modification of the AutoCAD support file search path. As the function proceeds, it gathers every key found within the two hives, HKCU and HKLM, and writes the current user hive to a string. This string is then searched for a particular known value. If found, then the routine does nothing and exits cleanly. If not found, then this new value is added to the top of the ACAD environment variable, aka the AutoCAD Support File Search Path, then the rest of the variable is written back and the result is written back to the appropriate registry key.

The result is that the next time your chosen product is launched with the same profile, this new path is included and any pre-defined automation files such as acad.lsp or acaddoc.lsp will now be found and automatically engaged. We will take full advantage of this in the next article when we explore the code contained within the acad.lsp file. I hope you found this useful. See you on the forums!

Submitted by Richard Binning, AUGI board member.

(Discuss this Article! in AUGI's new Discussion Forums.)