Attach Information to Drawing Objects

sbcad

Hi,

is it possible, to attach additional information to drawing objects. The same as with attributes and blocks, but without creating blocks. I.e. give a certain name to polyline, line, point, hatch aso?

Thanks

Michael Mayer

Not the best or realistic idea :

• create Polyline
• create Region from it (optional)
• assign a BIM Tag (BIM Slab ?)
• > give it a name and other info

James Maeding

@sbcad
Yes, via programming. The data is called "xrecords", and I use it extensively (lisp and .net).
You would need a command to add the data, then read and do something with it.
I would be lost without xrecords.

Roy Klein Gebbinck

You can also consider Extended Entity Data, a.k.a. Xdata. You can add Xdata programmatically (f.e. with Lisp code) but also with the _EditEData command (Tools > Entity Data > Create or Edit Entity Data).

James Maeding

@Roy Klein Gebbinck
Note that xdata is limited in size to 32k I think. I used to use it but hit the limit now and then.
Good tip on the (Tools > Entity Data > Create or Edit Entity Data), I did not know about that, or forgot.
One thing I consider critical to storing data on an entity is to only store one string per "application".
That string will be a serialized list. You need functions to serialize and deserialize from list to string and back.
Why? because there are bugs with lisp and .net when dealing with "resultbuffers" (arx name for lisp lists).
They do not happen with strings, and also many times you will want to save data to file and those same functions come into play.
I know I went off the deep end with this comment, but once you get to only using one string, the sky is the limit.
You can do as complicated things as you want, storing whole trees of data (lists of lists of lists...) on an entity.

Roy Klein Gebbinck

Actually the max size is 16k (16383 bytes). At least according to the xdroom function. I have never hit that limit, nor have I experienced issues with (X)data that is not in a string format. One of the advantages of using Xdata is that you can use it in ssget filters. For this reason I would advise to always use Xdata, even if most of your application data is stored in Xrecords.
Note that BricsCAD offers more than AutoCAD here: you can also filter for group codes inside the application Xdata.

James Maeding

@Roy Klein Gebbinck
So long as people don't start creating excess "regapp" entries like eagle point did years ago. They realized if they made 1 regapp per entity, you could use it for filtering. It works well, but then cause the regapp "virus" I've fought against since R14 and its still a main dwg problem in southern california at least.
The filtering beyond that sounds great, you seem quite on top of the bcad enhancements!

Jason Bourhill

@James Maeding said:
Why? because there are bugs with lisp and .net when dealing with "resultbuffers" (arx name for lisp lists).

You should really temper these comments relative to the platform that you've formed them on:
1. (/= "AutoCAD" "BricsCAD") An issue you find in one isn't necessarily going to be present in the other. In regards to LISP there are many things that are possible in BricsCAD LISP that aren't AutoLISP. In general BricsCAD LISP is more tolerant, and it's more informative if there is a problem.
2. If you strike a bug in BricsCAD, then please report it, there's a good chance that you'll be successful in getting it fixed. I've raised many queries related to LISP and when it's been shown to be an issue it has been promptly fixed.

Regards,
Jason Bourhill
BricsCAD V20 Ultimate
CAD Concepts

Patrik Sparrman

One thing I would love ti see is "entity data" fields that reflects attributes like length/radius/area of the entity. This would be really useful and updated live without LISP intervention.

James Maeding

@Jason Bourhill
I agree the bcad support crowd is top notch.
The single string trick is still something I think is most robust for medium to large levels of data stored. It was bug driven at first, but not now for me.
Its one of those things where once you see a bug, and cannot troubleshoot why its happening, its hot lava - you work around it.
It may not even be a bug, but then a mistake I believe.
Anyway, when the ODA is replicating acad behavior, I would bet it replicates that "feature".
Either way, I write data to entities and files too so serialization is a necessary part of slinging data around and fits entity data storage nicely.
I am happy to share routines with anyone wanting to get into this.
I use it for both entity data, and dictionary storage for general dwg settings of my own, or history of who was in a dwg.