I concur with both of your positions ... however, what you see as ordinary and necessary data attached to objects, including extension dictionaries and all the other stuff commonly attached to objects, I see as bloat .. pure and simple ..
Sorry, have to disagree.
AutoCAD core features (like fields, Annotation, draworder, and so on)
use interobject referencing and extension dictionaries.
That is not 'bloat', no more than a new object or DXF field is bloat.
The use of extension dictionaries allows additional information to be
attached to objects in a way that is both generic and transparent
(e.g., does not break compatiblity with older applications that do not
know anything about it).
... and I copy your widget and edit it to make a new widget ... now you
get the drawing back and suddenly you have incorrect data, the drawing
has been corrupted and is useless for the purpose of the xdata being there.
My 'widget' is not a widget unless my widget application is present and
running. You see, my widget application has deep-clone reactors that
allow it to resolve issues like collisions of names; part numbers; and
other unique or special values that it stores in xdata or in xdictionaries,
when one of my widgets is copied.
And, when I get a drawing back from someone who has copied my
widgets without my widet application, my widget application does an
audit and resolves all of the things you seem to have mislead yourself
into believing are basic design failures, but in fact, are really just a
demonstration of your own limited understanding of the problems, and
the ways and means that are available to solve them, all of which are
beyond the reach of a 'programmer' who is confined to LISP or VBA.
If you can honestly, without any reservation whatsoever tell me that this scenario absolutely never ever happens, then we can begin discussing how you are living in a bubble.
Considering the fact that you obviously do not even realize that
the code you posted doesn't do what you think it does, I would
have to say that the bubble that you're living in is quite small.
You see, when you do this:
(entmake (entget <ename> ))
You are
not creating a copy of the object
whose entity name is passed to (entget).
Given the tone of your response, I'm not going to take the
trouble to edcuate you on why that is, other than to tell
you that doing the above can easily result in a new object
which has properties that are not the same as the original
(e.g., the color, lineweight, layer, and so on).
To help you along your way to figuring out why, look at
and try to think about what I said in my original response:
(entmake) and (entget) do not have compatible argument/result lists.
So, given the fact that you don't even see or can't understand the
basic problem with your approach (that (entmake (entget <ename>>))
does not produce an identical copy, with or without xdata), It's difficult
to take the rest of what you have to say, seriously.
You might want to rethink your approach to deleting xdata.
(entmake) and (entget) do not have compatible argument/result
lists. Worse, you would also be trashing any references to the object
(e.g., draworder, field references and so on) not to mention its
extension dictionary.
Not sure about in .net, but the process is pretty simple ... I do the same think in lisp very easily .. perhaps this code will give you some insight.
(defun c:delxd (/ ent elist)
(setq ent (car (entsel)))
(setq elist (entget ent))
(entdel ent)
(entmake elist)
)
The process is simple ... grab the entity and store the entity data in a variable, but don't store the XDATA, then delete the original object and recreate the object using the saved data.
............. Worse, you would also be trashing any references to the object
(e.g., draworder, field references and so on) not to mention its
extension dictionary.
The process is simple ...
Yep, it's frustrating to find that "someones" code has wiped out your data ...
I concur with both of your positions ... however, what you see as ordinary and necessary data attached to objects, including extension dictionaries and all the other stuff commonly attached to objects, I see as bloat .. pure and simple ..
In today's world of files being shared by multiple offices, with multiple diciplines and multiple program types i.e. LDD, ADT, C3D, not to metion the blevy of add-on programs designed to "improve" our productivity and workflow, what is/was a splended idea of attaching data to objects has become a wholesale nightmare ... Lets presume you draw a line ... you attach xdata to that line because it represents something ... I don't care what .. lets just say that it is important ... now someone else comes along and says .. "Hey! .. I need to offset that line extend it to this object over here, trim it here, rotate it a bit ... then match layer to this object over .. here .. "
If you can honestly, without any reservation whatsoever tell me that this scenario absolutely never ever happens, then we can begin discussing how you are living in a bubble.
A copied object with attached xdata has the exact same xdata as the source object .. maybe it shouldn't .. but it does .. now the cool thing about that is, that when you draw a single widget and attach xdata to it, you can array it and get multiple copies with the same data already attached ... but lets just say that I come behind you and don't know that each widget has a part number, hard reference to another object or whatever .. something that makes the drawing "smart" ... and I copy your widget and edit it to make a new widget ... now you get the drawing back and suddenly you have incorrect data, the drawing has been corrupted and is useless for the purpose of the xdata being there.
If the answer is that you don't use drawings that have been edited outside of your office, then fine ... if the user dumps your extraneous information, it is of absolutely no consequence to you.
But lets assume that you do use the drawings that have been edited outside of your office ... suddenly you are hit with the prospect that you can no longer trust the data, even if they didn't strip it out, they could have copied an object and made your programming come up with erroneous data or worse, crash because something in the program does not know how to handle the object that has been edited. So, regardless if the other party killed all of your "smart" objects or not, you can no longer use the objects in the drawing in their "smart" capacity.
Personally I view xdata in the same light as the dreaded educational plot stamp .. it is intrusive and will grow unencumbered severely bloating the size of the drawing, thus affecting the operation of the software and the required hardware to run it. Oh .. and I feel the same way about saved layer states, views and xrecords .. they have a place and are useful, but they are too persistant and used much too often.