Drawing custom properties can be used as a container to store per-drawing data, which is persisted with drawing file.
Drawing custom properties can be accessed for read/write via COM API since AutoCAD 2002. AutoCAD ObjectARX .NET API provides DatabaseSummaryInfo structure and DatabaseSummaryBuilder class to deal with drawing custom properties.
In this post, I attempt to put together some code that makes the process of attaching custom process configurable. That is, using the code presented here, one can easily configure what custom properties he/she wants to attach to drawing (property name, data type).
Firstly, here is the first part of code that defines 2 classes: CustomProperty and CustomProperties:
The code shown above is fairly straightforward.
Now, a bit talk on "configurable". It is possible that business requirement to drawing custom properties can change due many different reasons. As a well-developed application, we all hope the application we developed have quite flexibility to adopt reasonable change without having to change the code each time business requirement changes, or at least minimize the possible code change. In the case of drawing custom properties, the goal is that when the business operation wants to add new custom property, to remove existing custom property, or to change existing custom property (its name, data type...), it would be ideal that these required changes can be done outside the application code and after the changes, the application still work the same way while he required changes to custom properties applied correctly. So, we need to separate custom property requirement and custom property applying as two different parts, then we use an Interface as the bridge to connect the 2 parts. In the first part (I create a class MyDrawingProperties, more details on it later), the code is responsible to set up custom properties in a drawing, according to custom property requirement supplied by second part, which is an class that implements a interface, called ICustomPropertiesFactory. Its name suggests that this interfaced class generates a set of custom properties according to business requirement and hand it over to the first part code for setting them up in drawing.
Here is the interface I use:
Now, I can decide how and where I'd like the drawing custom properties is configured and where the configuration is persisted. The idea is that when business requirement changes (i.e. required drawing custom properties change due to drafting process change), I do not want to modify my code, at lease the code that actually writes/reads a drawing's custom properties while the CAD management is free to add new custom properties, remove existing custom properties. The trick, of course, is to implement the aforementioned Interface.
In this example, I use an XML to configure drawing custom properties. That is, if the CAD operation wants to make changes to currently used drawing custom properties (adding new properties or removing existing properties), simply going into the XML file and update it as needed. No code change is required. In reality, I'll prefer using database to persist custom property configuration than using XML file, though, especially in an enterprise environment.
Here is the XML file that defines drawing custom properties to be used:
Here is the code that implements the interface ICustomPropertiesFacotry:
As you can see, the class does only one thing: generating a set of custom properties that defined in the persisted custom property configuration. Obviously, if the custom property configuration is stored in other format, such as in database, I can write different class (for example "CustomPropertiesSqlFactory") to read the configuration by implement the same interface.
Now, with drawing custom properties being defined outside the code that runs in AutoCAD, I can then focus on reading/writing drawing custom properties in AutoCAD without having to worry what if the requirement to custom properties changes later.
Here is a class called MyDrawingProperties that is derived from Autodesk.AutoCAD.DatabaseServices.DatabaseSummaryInfoBuilder:
One thing to mention: in the LoadSetting() method, for simplicity, I just test if the passed in parameter is a string representing a XML file name. If other type/format of custom property configuration is used, the hard coded approach obviously is not a good practice. I may post in future on a topic regarding how to load different classes that implement the same interface via configuration.
From the code we can see, the code acts upon a set of custom properties defined in custom property configuration. The interface ICustomPropertiesFactory effectively separates how custom properties is handled in AutoCAD and how they are defined.
Finally, here is the code that actually puts everything together and makes them useful in AutoCAD:
You may have noticed there is ICustomPropertyValueProvider type used in "EditMyProps" command. I'll explain it later.
After running command "AttachMyProps", use "DwgProps" command to open "Drawing Properties" dialog box. You should be able to see all the predefined custom properties defined in the XML file (or other custom properties configuration source, for that matter) are now available in the current drawing. Running command "ClearMyProps" clears these predefined custom properties.
Now let's look into ICustomPropertyValueProvider interface. Custom properties only are useful when they carry meaningful values. In reality, the custom properties could be populated in many ways: manually, or most desirably , automatically with data from production data source, such as project management database, document management system...So, once we have a way to attach custom properties to a drawing, there should be some kind of mechanism to populate custom properties. Since the data used for custom properties could from very different types of source, such as databases, XML file, text file, Excel sheet, or web/WCF services, it is important to define an interface for populating custom properties, so that the code that actually populates custom properties does not have to be changed when data source changes. Hence the ICustomPropertyValueProvider interface. In my case, I want to manually populate the custom properties by using a dialog box to get user inputs. So, I create a class CustomPropertyValueManualProvider, which implements ICustomPropertyValueProvider:
There is no need to pay much attention on how the dialog box is designed to get user input here. All we need to know is that calling ICustomPropertyValueProvider.GetCustomPropertyValues() method would return a Dictionary object with each custom property's name as key. Notice that the method takes a file name as one of the input parameters. I assume data used for custom properties can be identified from the data source by drawing's file name in many cases. If drawings in an office are managed in some sort of document management system, such as Vault, SharePoint, then drawing might be identified by particular identifier other than file name.
Obviously, if you want to populate custom properties with data from certain data source other than manual input, say, from SharePoint drawing library, you just need to create a class that implements ICustomPropertyValueProvider (you could call it CustomPropertyValueSharePointProvider). You then write code in the class's GetCustomPropertyValues() method to grab data from SharePoint drawing library. Whatever you do here, there is no need to change code in MyDrawingProperties to update custom property values (by calling its ApplyCustomProperties(ICustomPropertyValueProvider provider) method).
Here is a video clip to show how the code works in AutoCAD.
Download source code here.