Topic: Storing Per-Drawing Form Settings

[Rico1919]

Hey guys, first I wanted to say thanks for all of the help I've gotten just as a reader; this site has been invaluable.

I have run into a design decision though and was hoping to get some input on.  I have a form that is reading queries from an Access database and then inserts AutoCAD tables based on a few settings in the form (a set of radio buttons, a checkbox, and a runtime generated checkbox list).  I would like to be able to store the user choices for each of these controls for subsequent runs.

The choices will be job-specific so I could hypothetically store them back to the job's Access database but that would require manipulating the structure of the databases in code since they are already created.  I have done this in a pinch in the past before but I was looking for something a little cleaner.  A previous version of this program manipulated the custom properties in the summary info of a drawing and stored/read preferences from there.  Again, didn't seem like the most efficient or clean way to attack it.

I have looked into a few other options like extended dictionaries, xdata, etc. but none seem to be exactly what I am looking for.  I really just need to store a lookup of boolean's based on runtime generated keys.  Any recommendations on the best way to skin this cat?  Most extended dictionaries seemed to be on objects but can I store one of these for the drawing with just some booleans as values?  Any help would be greatly appreciated.

Thanks,
Mike

[dgorsman]

I regularly add Extension Dictionaries to the Named Object Dictionary for document-level storage, same way as AutoCAD stores such information e.g. group names.

[Rico1919]

Thanks for the response.  An Xrecord added to the NOD was the way that I was leaning but it seems like quite the pain to work with for such a simple task.  Also, correct me if I am wrong, but it does not appear that I have the ability to simply store pairs of data but rather single entries.  I could tie them together using string manipulation or offset indices but this again seems like more trouble than it is worth.  The UserData stored in the Document object would be perfect if it were persistent.  Is there a simple, persistent implementation of this functionality?

[dgorsman]

Rather than store XRecords directly off the NOD, I create several nested Extension Dictionaries to keep things organized.  Also, XRecords *can* store multiple values each, based on your needs.  For example, I store some layer information as a name (string), an AutoCAD color (Color), a linetype name (string),  a freeze state (integer-coded boolean), and a number of other settings all in a single XRecord.  I would suggest reading the DXF documentation when assigning values to XRecords - its a little more revealing about which values are used, where, and why.

Management is quite simple - establish a standard method of how you read and write the information, then call the appropriate interface.  Its pretty much the same process used regardless of how custom information is implemented.

[Jeff H]

Welcome Rico1919,

If you add a ExtensionDictionary in the NOD you basically have Dictionary<string,DbObject> so your xrecords are keyed by name. You could just use the names to represent true or false by adding for true or removing them for false, but I get how that it doesn't feel right that situation.

For mapping layers to insert blocks on from library files I like adding the objectid of layer to BlockTableRecords as a HardPointer in library files so they get cloned with them and on insert just set current layer to that, and easy to let user update to another layer differently in other drawings.

You mentioned job specific and custom properties in summary info, and not sure of specifics but for things that job specific for me which could be 1 drawing but almost always(I do not think ever had job with 1 drawing) multiple drawings a property is stored in custom properties that associates drawing with job and from there can use job identifier to get data, settings, etc.... for job.