Somewhere I read that xdata is more reliable than ldata... Can't find where I read this... Some thoughts if you know...Hi Marko, I quote here some considerations on this subject from my book "AutoCAD expert's Visual LISP", Chapter 23:
ActiveX Functions for XDATA, XRECORD and Dictionaries.You can find more information in my blog http://lispexpert.blogspot.com/
XDATA, XRECORD and Dictionaries emerged in the pre-ActiveX AutoCAD era. Although there are equivalent ActiveX methods and properties, processing from Visual LISP functions has no disadvantages. Quite the contrary, the ease with which LISP creates and processes data lists represents an advantage over ActiveX methods that require packing data as safearrays.
But there is a simpler set of ActiveX dictionary functions. These dictionaries belong to a special type known as LDATA. We already used this format in the Chapter 1 Tutorial.
LDATA functions can save a lot of programming effort. In the following section we will summarize the use of these functions when dealing to storing non-graphical information in the drawing, with or without links to graphic entities.
23.5 LDATA Dictionaries.
We can distinguish between two different types of dictionary objects: the LDATA dictionary aimed at storing information in LISP format and dictionary objects composed by XRECORD entities in which information is managed using a DXF style coding. As we have seen, the XRECORD object dictionaries require considerable programming effort. But for LDATA dictionaries, Visual LISP provides a set of functions that ease their use.
Caution should be exercised when using this kind of object because the LDATA information for Release 2000 and above is not compatible with AutoCAD Release 14. If the drawing is saved in R14 drawing format information may be lost or corrupted. Although it's not likely today, a drawing to be used with such an old version should use XRECORD dictionaries. But everything is relative, since we know that XRECORD would be lost when using the drawing in a release prior to R13c4, and XDATA would only survive the round trip to Release 11, but not beyond it.
There is no specific function for the creation of LDATA dictionaries. Adding data will automatically create them. The dictionary can exist by itself in the drawing with a name that identifies it, but it can also be attached to any drawing object.
Thanks, togores, though I have one direct question... How can I obtain list of all registered dictionary names registered through (vlax-ldata-put) function?This is a bit complicated, as LDATA dictionaries may be "named" or can be assigned to an entity. If it is named, it will be included in the Named Object Dicionary:
_$ (vlax-ldata-put "TESTDICT" "DATA1" "THIS IS A TEST")
"THIS IS A TEST"
_$ (vlax-ldata-get "TESTDICT" "DATA1")
"THIS IS A TEST"
_$ (entget (namedobjdict))
((-1 . <Entity name: 7ffff7038c0>)
(0 . "DICTIONARY")
(330 . <Entity name: 0>)
(5 . "C")
(100 . "AcDbDictionary")
(280 . 0)
(281 . 1)
(3 . "ACAD_CIP_PREVIOUS_PRODUCT_INFO")
(350 . <Entity name: 7ffff7049e0>)
(3 . "ACAD_COLOR")
(350 . <Entity name: 7ffff703bb0>)
(3 . "ACAD_DETAILVIEWSTYLE")
(350 . <Entity name: 7ffff704a30>)
(3 . "ACAD_GROUP")
(350 . <Entity name: 7ffff7038d0>)
(3 . "ACAD_LAYOUT")
(350 . <Entity name: 7ffff7039a0>)
(3 . "ACAD_MATERIAL")
(350 . <Entity name: 7ffff703ba0>)
(3 . "ACAD_MLEADERSTYLE")
(350 . <Entity name: 7ffff704150>)
(3 . "ACAD_MLINESTYLE")
(350 . <Entity name: 7ffff703970>)
(3 . "ACAD_PLOTSETTINGS")
(350 . <Entity name: 7ffff703990>)
(3 . "ACAD_PLOTSTYLENAME")
(350 . <Entity name: 7ffff7038e0>)
(3 . "ACAD_SCALELIST")
(350 . <Entity name: 7ffff7040c0>)
(3 . "ACAD_SECTIONVIEWSTYLE")
(350 . <Entity name: 7ffff704a10>)
(3 . "ACAD_TABLESTYLE")
(350 . <Entity name: 7ffff703c60>)
(3 . "ACAD_VISUALSTYLE")
(350 . <Entity name: 7ffff703ef0>)
(3 . "AcDbVariableDictionary")
(350 . <Entity name: 7ffff703ae0>)
(3 . "TESTDICT") ;; this is our dictionary
(350 . <Entity name: 7ffff704b50>))
If assigned to an entity it will be included as its Extension Dictionary:_$ (vlax-ldata-put (entlast) "ENTDATA1" "THIS IS ATTACHED TO A CIRCLE")
"THIS IS ATTACHED TO A CIRCLE"
_$ (entget (entlast))
((-1 . <Entity name: 7ffff704be0>)
(0 . "CIRCLE")
(5 . "236")
(102 . "{ACAD_XDICTIONARY")
(360 . <Entity name: 7ffff704bf0>) ;; this ename can be used to get the extension dictionary
(102 . "}")
(330 . <Entity name: 7ffff7039f0>)
(100 . "AcDbEntity")
(67 . 0)
(410 . "Model")
(8 . "0")
(100 . "AcDbCircle")
(10 2328.9 2020.6 0.0)
(40 . 178.42)
(210 0.0 0.0 1.0))
_$ (entget (cdr (assoc 360 (entget (entlast)))))
((-1 . <Entity name: 7ffff704bf0>)
(0 . "DICTIONARY")
(330 . <Entity name: 7ffff704be0>)
(5 . "237")
(100 . "AcDbDictionary")
(280 . 1)
(281 . 1)
(3 . "ENTDATA1") ;; this is our dictionary's name
(360 . <Entity name: 7ffff704c00>))
In my acaddoc.lsp I include a call to (vla-load-com) as I use a lot of ActiveX functions in my code, so I don't get the warning message about ActiveX not being loaded.Still my first question stands : What is better Xdata or Ldata and why?Here's a quote from a post by Tony Tanzillo on the Autodesk Lisp forum, from back in 2004. I have never used LData based on this.
LDATA is just a way to 'encrypt' your data in a dictionary, using a custom object. In fact, in some circumstances (opening a file by double- clicking in explorer) you can see proxy notices when you open a file with LDATA. The only thing LDATA offers is that it preserves the original list structure, which is something that is useful only to entry level programmers. The disadvantages is that it is a way to lock your data up in a way that can potentially render it completely inaccessible, which is what happened when R14 drawings were migrated to AutoCAD 2000. You can use Dictionaries and XRecords to store anything you can store in LDATA and can access it via any API you might choose to use. In short, stay as far away from LDATA as you can possibly get.Here's the link to the thread I found that in: http://forums.autodesk.com/t5/Visual-LISP-AutoLISP-and-General/What-about-ldata/m-p/941043#M139521
Are we not sufficiently beyond R14 that we no longer worry about that problem?
So I don't buy the argument that we should not use it because they MIGHT change it in the future. :-)