About Layer Description (LayerTableRecord.Description Property)

I recently worked on a project, where I need to get access to layer's description and based on the formatted description value to do something.

In AutoCAD's Layer Manager's view, the last column displays layer description. Of course the description is stored as LayerTableRecord.Description property. So, pretty simple, eh? Wrong. it is not as simple as it looks.

Whenever a new layer is created, a default description, which is the same as the layer name, is set, the Layer Manager shows. Also, if one tries to clear the description, the Layer Manager simply restores it back with the layer's name.

However, when trying to use code to access LayerTableRecord.Description property, it returns empty (String.Empty).

That means, the default layer description appearing in Layer Manager looks just displayed by Layer Manager if the description is not set explicitly. If we edit the layer description in the Layer Manager, then, yes, the description will be assigned to the layer (LayerTableRecord) with one exception: you cannot edit the description as the same as the layer name (i.e. you clear the appeared "fake" layer description, and then enter the layer name as the description), the description in LayerTableRecord remains empty.

However, you can use code to set LayerTableRecord.Description with the same text value as layer name (i.e. LayerTableRecord.Description property can be set via code to whatever value you want); or, in Layer Manager, you can first set the description to nay value other than empty text or layer name, then again you can set it back to the layer name. This time, the displayed description (the same as layer name) is really assigned to the LayerTableRecord.Descriotion property, not a "fake" value made up by Layer Manager.

So, I'd consider this is a bug of Layer Manager: if AutoCAD wants to give a layer a default description when a new layer is created, it should do so, not left it empty; and if the Description property is empty, the Layer Manager should leave it alone, not display a fake, misleading value.

However, by Layer Manager, I mean the "newer" paletteset style, floating window version (since AutoCAD 2009, I think). If open the old "Layer Properties Manager" modal dialog box (with "LayerDlgMode" system variable set to 0), the description in the dialog box is displayed correctly (emtpy) when a new layer is created. This convinces me that the issue I described here is a bug of Layer Manager (since AutoCAD 2009!).

Custom On Demand Loading

Most people, including myself, who start learning AutoCAD .NET API, would be wondering, after getting passed the first "Hello World" command tutorial, how to make their custom commands contained in the .NET DLL files available/loaded in AutoCAD, rather than entering command "NETLOAD" to manually load the DLL file. Then when they study/learn more, they would know a few ways to load the .NET DLLs into AutoCAD automatically: using acad.lsp to load at AutoCAD start-up; registering the DLL/commands in Windows Registry, so that the DLL will be loaded automatically when a command defined in a DLL is called and the DLL has not been loaded; or using AutoCAD's built-in Autoloader mechnism, where an XML file defines how a DLL file is loaded.

The company I work for is a huge one with offices allover the world, and the division I belong to has many offices scattered every corner of the country. So, even the entire division provides the same or similar services to the same industries, meaning the business operation processes are the same or very similar, our CAD applications still have to be grouped according to business factors, such as regions, industries...This results in scores of .NET add-in DLLs being developed, and many more are coming.

Originally, we had simply loaded all available .NET DLLs at AutoCAD start-up. But later on, with more and more .NET applications being developed for different offices/regions/industries, it does not make much sense any more to load all DLLs at AutoCAD start-up because many of them only get used in one AutoCAD session when a drawing is from particular project. However the reality is that our CAD users are trained/expected to work all project country-wide and they want a corresponding set of CAD applications to be loaded automatically based on the project (i.e. when a drawing in a project is opened, that set of tools should be available).

Obviously, the existing .NET DLL auto-loading mechanism (especially the Windows Registry demand loading and AutoCAD's AutoLoader) is not enough to deal with this situation.

Acad.lsp/AcadDoc.lsp can be used for this, of course: we can use LISP code to determine the DLL loading conditions (drawing's project, thus region, industry,...), then load the corresponding .NET DLLs.

Here I tried a custom .NET DLL demand loading solution, which is very easy to configure when a .NET DLL needs to be loaded automatically according to some conditions. 

The Scenario

1. There are 2 sets of CAD tools contained in 2 DLL files: 

ToolSetA.dll: it needs to be loaded when a drawing from project A, located in region "AAA" is opened in AutoCAD. This DLL file defines 2 commands: "ADoWorkOne" and "ADoWorkTwo".

ToolSetB.dll: it needs to be loaded when a drawing from project B, located in region "BBB" is opened in AutoCAD. This DLL file defines 2 commands: "BDoWorkOne" and "BDoWorkTwo".

The commands in these 2 DLL files do nothing other than showing AutoCAD alert message box.

2. The 2 DLL files are not loaded on AutoCAD start-up, nor other AutoCAD built-in on demand loading mechanism is applied to.

3. If a drawing from project A or project B is opened in AutoCAD, ToolSetA.dll or ToolSetB.dll should be loaded automatically if the DLL file has not been loaded into this AutoCAD session.

The Solution

My solution includes 2 parts: a set of configurable settings, which defines the on demand loading condition (which DLL files to be loaded for particular project location), and an IExtensionApplication class that dynamically loads DLL file into AutoCAD according to the settings. Of course the IExtensionApplication class itself has to be loaded in AutoCAD, for example, using Acad.lsp.

So, I created a class DllModule, and DllModuleCollection to hold and load the setting data:

using System.Collections.Generic;
using System.Linq;
using System.Configuration;
 
namespace DemandLoading
{
    public class DllModule
    {
        public string Region { set; get; }
        public string[] DllFileNames { set; get; }
        public string[] CommandNames { set; get; }
        public string ModuleName { set; get; }
    }
 
    public class DllModuleCollection : List<DllModule>
    {
        public DllModule GetDemandLoadModule(string region)
        {
            foreach (var module in this)
            {
                if (module.Region.ToUpper() == region.ToUpper())
                {
                    return module;
                }
            }
 
            return null;
        }
 
        public IEnumerable<DllModule> FindDemandLoadMuduleByCommand(
            string commandName)
        {
            var lst = new List<DllModule>();
 
            foreach (var module in this)
            {
                bool match = false;
                foreach (var cmd in module.CommandNames)
                {
                    if (cmd.ToUpper() == commandName.ToUpper())
                    {
                        match = true;
                        break;
                    }
                }
 
                if (match) lst.Add(module);
            }
 
            return lst;
        }
 
        public static DllModuleCollection LoadModuleListFromAppSettings()
        {
            var modules = new DllModuleCollection();
 
            Configuration config =
                ConfigurationManager.OpenExeConfiguration(
                    System.Reflection.Assembly.GetExecutingAssembly().Location);
            if (config.HasFile)
            {
                var moduleNames = 
                    config.AppSettings.Settings["Dll Modules"].Value.Split('|');
                foreach (var moduleName in moduleNames)
                {
                    var setting = config.AppSettings.Settings[moduleName.Trim()];
                    var data = setting.Value.ToUpper().Split('|');
 
                    try
                    {
                        string region = null;
                        string[] dlls = null;
                        string[] cmds = null;
 
                        foreach (var item in data)
                        {
                            string val = item.Trim();
                            if (val.StartsWith("REGION:"))
                            {
                                region = item.Substring(7);
                            }
                            else if (val.StartsWith("DLLNAME:"))
                            {
                                dlls = val.Substring(8).Split(',');
                            }
                            else if (val.StartsWith("COMMANDS:"))
                            {
                                cmds = val.Substring(9).Split(',');
                            }
                        }
 
                        if (region!=null && dlls!=null && cmds!=null)
                        {
                            var module = new DllModule()
                            {
                                ModuleName = moduleName,
                                Region = region.Trim(),
                                DllFileNames = (from d in dlls select d.Trim()).ToArray(),
                                CommandNames = (from c in cmds select c.Trim()).ToArray()
                            };
 
                            modules.Add(module);
                        }
                    }
                    catch { }
                }
            }
 
            return modules;
        }
    }
}

I use app.config added into the DLL project to store the settings:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="Dll Modules" value="Tool Set A | Tool Set B"/>
    <add key="Tool Set A" value="Region: AAA | DllName: ToolSetA.dll | Commands: ADoWorkOne, ADoWorkTwo"/>
    <add key="Tool Set B" value="Region: BBB | DllName: ToolSetB.dll | Commands: BDoWorkOne, BDoWorkTwo"/>
  </appSettings>
</configuration>

The app.config file is compiled to xxxxx.dll.config and goes with the DLL file.

Now this is the IExtensionApplication class OnDemandLoader, which does the work of loading corresponding DLL files on demand:

using System;
using System.Linq;
using System.Text;
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.Runtime;
using CadApp = Autodesk.AutoCAD.ApplicationServices.Application;
 
[assembly: CommandClass(typeof(DemandLoading.OnDemandLoader))]
[assembly: ExtensionApplication(typeof(DemandLoading.OnDemandLoader))]
 
namespace DemandLoading
{
    public class OnDemandLoader : IExtensionApplication
    {
        private static DllModuleCollection _dllModules = null;
 
        private bool _newDocAdded = false;
 
        public void Initialize()
        {
            var dwg = CadApp.DocumentManager.MdiActiveDocument;
            var ed = dwg.Editor;
 
            try
            {
                ed.WriteMessage(
                    "\nInitializing \"ON DEMAND LOADER\"...");
 
                _dllModules = DllModuleCollection.LoadModuleListFromAppSettings();
                if (_dllModules.Count==0)
                {
                    ed.WriteMessage(
                        "\nNo Dll module is configured for demand loading.\n");
                }
                else
                {
                    CadApp.DocumentManager.DocumentCreated += 
                        DocumentManager_DocumentCreated;
                    CadApp.DocumentManager.DocumentBecameCurrent += 
                        DocumentManager_DocumentBecameCurrent;
 
                    foreach (Document doc in CadApp.DocumentManager)
                    {
                        doc.UnknownCommand += Document_UnknownCommand;
                    }
 
                    EnsureRegionModuleLoaded();

                    ed.WriteMessage(
                        "\nON DEMAND LOADER loaded successfully.\n");
                }
            }
            catch(System.Exception ex)
            {
                ed.WriteMessage(
                    "\nInitializing \"DEMAND LOADER\" failed:\n{0}\n", ex.Message); 
            }
        }
 
        public void Terminate()
        {
        }
 
        #region private methods
 
        private void Document_UnknownCommand(
            object sender, UnknownCommandEventArgs e)
        {
            string cmd = e.GlobalCommandName;
 
            var modules = _dllModules.FindDemandLoadMuduleByCommand(cmd);
            if (modules.Count() > 0)
            {
                //Prompt user to manually load the module that contains the command
                var msg = new StringBuilder();
                msg.Append("The *.dll module containing command \"" + cmd + "\"\n" +
                    "is not automatically loaded according to the project." +
                    "\n\nFollowing DLL file(s) must be loaded:\n\n");
                foreach (var m in modules)
                {
                    foreach (var dll in m.DllFileNames)
                    {
                        msg.Append(string.Format("\"{0}\"", dll));
                    }
                }
                msg.Append(
                    "\n\nYou can manually load the DLL file(s) with command \"NETLOAD\".");
 
                CadApp.ShowAlertDialog(msg.ToString());
            }
        }
 
        private void DocumentManager_DocumentBecameCurrent(
            object sender, DocumentCollectionEventArgs e)
        {
            if (_newDocAdded)
            {
                EnsureRegionModuleLoaded();
                _newDocAdded = false;
            }
        }
 
        private void DocumentManager_DocumentCreated(
            object sender, DocumentCollectionEventArgs e)
        {
            _newDocAdded = true;
            e.Document.UnknownCommand += Document_UnknownCommand;
        }
 
        private void EnsureRegionModuleLoaded()
        {
            //Get project region from drawing (USERI1)
            string region;
            var regionCode = Convert.ToInt32(CadApp.GetSystemVariable("USERI1"));
            switch (regionCode)
            {
                case 10:
                    region = "AAA";
                    break;
                case 20:
                    region = "BBB";
                    break;
                default:
                    region = "";
                    break;
            }
 
            //Get demand laoding DllModule info
            var module = _dllModules.GetDemandLoadModule(region);
            if (module != null)
            {
                EnsureModuleLoaded(module);
            }
        }
 
        private void EnsureModuleLoaded(DllModule module)
        {
            string path = System.IO.Path.GetDirectoryName(
                System.Reflection.Assembly.GetExecutingAssembly().Location);
 
            foreach (var dllFile in module.DllFileNames)
            {
                string file = path + "\\" + dllFile;
                if (!ExtensionLoader.IsLoaded(file))
                {
                    ExtensionLoader.Load(file);
                }
            }
        }
 
        #endregion
    }
}

In the OnDemandLoader class, the key logic is to identify the DLL file loading condition when a drawing is created in AutoCAD. In this case the condition is the project's region of current drawing. Normally, the project a drawing file belongs to can be decided by the file name, file storage folder, and so on. In this article, I use system variable USERI1 stored in drawing to stimulate the project's region, just to make the code run-able.

The Result

With the code completed, I tested the in following steps:

1. Start AutoCAD, and manually load the OnDemandLoader into AutoCAD (DemandLoading.dll). In real use, it would be automatically loaded on AutoCAD start-up, of course.

2. Since the currently opened drawing in AutoCAD does not belong to Project A (in region "AAA"), nor Project B (in region "BBB"), thus the 2 DLL files (ToolSetA.dll and ToolSetB.dll) are not loaded.

3. Enter one of the commands defined in the 2 not loaded DLL files, user is prompted for it.

4. Open 2 drawings prepared for Project A and Project B (in the 2 drawings, system variable "USERI1" has been set to indicate the project's region). Upon the 2 drawings' opening, message shown at command line indicates that the corresponding DLL file (ToolSetA.dll or ToolSetB.dll) is loaded, because each of these DLL files implemented IExtensionApplication.Intialize() method, where loading message is printed at command line.

5. With the project drawing open, enter commands defined in the on demand loading DLL files. It proves that the commands work as expected, thus on demand loading is done successfully.

6. Close one of the project drawing and re-open it. This time, no DLL loading message shows at command line, because the corresponding DLL file has been loaded previously.

See this video clip showing the test steps.

As the code shows, the key logic in this solution is simply carefully designing the settings to define DLL loading conditions and make sure the code can identify if the conditions are meet at run-time under different AutoCAD states (in my case, it is when document is created and becomes current the first time). The on demand loading process then does its work completely according to the settings, which can be updated whenever it is necessary without breaking the on demand loading process.

In the OnDemandLoader class I also handles Document.UnknownCommand event so that when a CAD application/custom command is tried in a drawing of not intended project, user is warned/prompted. Obviously, we could develop our own on demand loading process in this event handler: whenever a unknown command is entered, let the code to somewhere to look up where the command is defined and what the containing DLL file is; then load the DLL and reinvoke the command. I guess this is the logic AutoCAD's built-in on demand loading (using either Windows Registry or Autoloader) uses.