@Anonymous wrote:
Okay, I am a newbie to AutoCAD's API, but do understand C# (Mid Level). We use a 3rd party software that runs on top of AutoCAD and uses Xdata, as its primary source of storing information to objects. Different sections of the application uses its own application name. What I am having trouble is understanding the Code "Numbers" (Code 1002, ASCII string: 1"). I understand the data types, but not the "Code 1002" and at that they are repeated several times with different data types and values. So if one pulls this information, who do you know which values you are extracting? Well intent is to try something like this:
- Create a grid view with some of these values. (maybe a tool palette?) What is the easiest for a beginner?
- Be able to summarize the values in different reporting formats in the grid view?
- I need for it to read the xrefs in the drawing as well. ( maybe add a toggle?)
- Be able to export the information out into excel or even use a excel template to write to and let it start to write at a certain row.
This would be a good start for me now. If anyone can point to where I can lean some of the bullet items, that would be very helpful. Sample code would also be appreciated\ and useful to get me started.
IMO, a good start would be to make extensive use of System.ComponentModel (particularly the TypeDescriptor class), to expose XData through it, which not only makes it easy to consume from your own UI, but also allows it to be used and recognized by AutoCAD's DataExtraction functionality. IOW, do not deal directly with Xdata. Instead, write classes that wrap the xdata and expose it as class properties.
By adding custom type descriptors for AutoCAD types, you can add custom properties to those types that are recognized by components like the PropertyGrid, DataGridView (when binding to a class), and so forth (but unfortunately not by AutoCAD's properties palette without a lot of very complicated coding and reliance on 'unsupported' wrappers for managed code, that are limited in their ability and extremely difficult to work with, so for exposing your xdata to AutoCAD's properties palette, you'll most likely have to resort to C++ and the native API).
DataExtraction already has the ability to extract data to Excel, or to a formatted Table in a drawing, so a great deal of the functionality that you would probably want or need is already there, because DataExtraction will see and use your xdata if you expose it as custom properties on AutoCAD objects.
To expose custom properties on AutoCAD types, you have to do some work by creating CustomTypeDescriptors and TypeDescriptionProviders that will allow a call to TypeDescriptor.GetProperties() on an AutoCAD object to return your custom properties as well as those explicitly declared on the types.
As far as what the cryptic DXF codes mean, see the DXF documentation mentioned in other replies. To summarize, you can treat xdata as an arbitrary stream of data that only your application understands, where DXF codes are metadata that only describes the data type and nothing else. Hence, you would just develop a stream reader and writer that works with xdata rather than a file. It's also common to include a value that indicates the version of the application that wrote the xdata, so that if there are subsequent changes to its structure, future versions of your app will be able to read the xdata regardless of what version of the app wrote it.
