Topic: how to delete xdata?

[itcad]

hi:
    please tell me how to delete xdata?

[Keith™]

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.

Code: [Select]

(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.

[Chuck Gabriel]

In VBA (and probably .NET as well) the method is to overwrite the xdata for the desired regapp name with a list that consists of nothing but the regapp info.

Code: [Select]

Sub eraseXdata(ByRef ent As AcadEntity, ByRef regAppName As String)
  Dim xDataType(0) As Integer
  Dim xDataValue(0) As Variant
 
  xDataType(0) = 1001
  xDataValue(0) = regAppName
  ent.SetXData xDataType, xDataValue
End Sub

Roughly equivalent C# code:

Code: [Select]

void eraseXdata(DBObject obj, string regAppName)
{
  obj.XData = new ResultBuffer(new TypedValue((int)DxfCode.ExtendedDataRegAppName, regAppName));
}


[TonyT]

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.

Code: [Select]

(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.

[Kerry]

............. 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 ...

[Keith™]

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.

Code: [Select]

(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.

[Kerry]

I concur with both of your positions ...

That was really all you needed to say. The rest is opinion,

[Chuck Gabriel]

I can see it both ways.  For your own drawings and your own data, you presumably want to be very careful about protecting it and maintaining it in its proper state.  For reference drawings used to coordinate with other trades, I wouldn't have any reservations about using brute force methods to prune the drawings down to a reasonable size.

Some of our clients routinely send us drawings in the ten to fifteen megabyte range, and they can be kind of clunky to work with before we hack them up.  My personal favorite is the thousands of layer filters that accumulate in their drawings as they reuse them from job to job.  If someone in our office commits the cardinal sin of copying and pasting something from one of these abominations into one of our drawings, we get all of those layer filters as an added bonus.

[MP]

I have mixed feelings about removing xdata, since there are equally valid reasons for protecting it as well as removing it. To wit, many of the programs I've written rely on the presence of xdata, be it placed and managed by my applications or third parties like Autoplant.

On the other hand, I've had clients specifically have me write lobotomy type applications -- to purge all xdata, dictionaries et al in order to sanitize 'intelligent' drawings for other purposes.

In either case I'd be very careful when shaking off xdata by deleting and recreating entities unless I fully appreciated all the ramifications of doing so, especially all the different means by which entity / object relationships exist, and subsequently can be broken.

Does Keith? In that I've no doubt.

Should the general viewing audience be warned? ABSOLUTELY.

So, if one knows what they're doing, this non destructive (in terms of retaining the original entity) may be of interest:

Code: [Select]

(defun _RemoveXdata ( ename appidlist / xdata )

    ;;========================================================
    ;;
    ;;  Caller's responsibility to ensure valid entity
    ;;  passed to function (including editable state)
    ;;
    ;;--------------------------------------------------------
    ;;
    ;;  Remove all xdata:
    ;;
    ;;      (_RemoveXdata ename '("*"))
    ;;
    ;;  Remove specific xdata, form 1:
    ;;
    ;;      (_RemoveXdata ename '("appid1,appid2"))
    ;;
    ;;  Remove specific xdata, form 2:
    ;;
    ;;      (_RemoveXdata ename '("appid1" "appid2"))
    ;;
    ;;  Remove wildcarded xdata:
    ;;
    ;;      (_RemoveXdata ename '("appid*"))
    ;;
    ;;========================================================

    (if (setq xdata (cdr (assoc -3 (entget ename appidlist))))
        (entmod
            (append
                (entget ename)
                (list
                    (cons -3
                        (mapcar
                           '(lambda (x) (list (car x)))
                            xdata
                        )   
                    )
                )   
            )
        )
    )
)

[Kerry]

........ since there are equally valid reasons for protecting it as well as removing it. ......

Absolutely agree. !

But that does not give anyone license to hose my data indiscriminately because it's simpler for him.
 
It makes me uncomfortable when a member of this forum who knows better proposes a solution that is destructive, and then cites his dislike of the storage mechanism as justification.

[MaksimS]

In my understanding, erasing other apps indicies beyond supported mechanisms (i.e. PURGE, WBLOCK...) is a no-no. Let me give you a hint:

1) Municipal cadastre uses a spatially enabled database to store geometry and accompanying data
2) When asked for a "copy" of a part of it's cadastre, municipality serializes requested data to a DWG file (in a very long transaction)
3) Resulting DWG circulates around the city (spatial planners, infrastructure organizations, etc) for days, even for months...
4) After a while, the very same DWG (or parts of it) end up waiting for a commit into the municipal database

If, for some reason, DWG-residing entity misses it's indicies, it won't get re-commited back to the database. End result? Subcontractors may lose months of their work, projects don't get finished on time, lots of money is wasted.

Regards,
Maksim Sestic

[Keith™]

........ since there are equally valid reasons for protecting it as well as removing it. ......

But that does not give anyone license to hose my data indiscriminately because it's simpler for him.
 
It makes me uncomfortable when a member of this forum who knows better proposes a solution that is destructive, and then cites his dislike of the storage mechanism as justification.

What you fail to realize is that once "your" drawing is in my hands .. unless I am working for you, the presence of the data is of no consequence.

I receive drawings occasionally where each object in the drawing has the maximum amount of XData attached and there can be no more ... and there is so much overhead that what should be a 100k drawing ends up being over 3mb ... perhaps that data is important to you ... but it is unimportant to me and the task I have at hand. So if your extra 2.9mb of data causes me grief, I call out the databegone squad.

[TonyT]

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:

Code: [Select]


     (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.

Code: [Select]

(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.

[MP]

Gentlemen, before this turns into a bit throwing contest I encourage you to make the attempts to speak to each other cordially and respectfully. Thank you.

[itcad]

In VBA (and probably .NET as well) the method is to overwrite the xdata for the desired regapp name with a list that consists of nothing but the regapp info.

Code: [Select]

Sub eraseXdata(ByRef ent As AcadEntity, ByRef regAppName As String)
  Dim xDataType(0) As Integer
  Dim xDataValue(0) As Variant
 
  xDataType(0) = 1001
  xDataValue(0) = regAppName
  ent.SetXData xDataType, xDataValue
End Sub

Roughly equivalent C# code:

Code: [Select]

void eraseXdata(DBObject obj, string regAppName)
{
  obj.XData = new ResultBuffer(new TypedValue((int)DxfCode.ExtendedDataRegAppName, regAppName));
}


it's ok.
thanks.

[TonyT]

Hi Mike. Everyone here seems to be confused about what I
talked about in my original post.

The issue I raised about Keith's approach has nothing to do
with whether deleting xdata is or isn't appropriate.

It has to do with his method of doing it, which doesn't do
what some may think it does.

To demonstrate, draw a circle with the current color set to
'BYLAYER', and the current layer's color set to 7 (the default).

Next set the current color in the editor to red, or something
other than BYLAYER, and then do this:

   (setq circle (entget (entlast)))

Move the circle just drawn a bit so the 'copy'  is not coincident
with it, and then do this:
 
   (entmake circle)

What color is the original circle, and what
color is the 'copy' of the circle created with
(entmake) ?

That's what I meant by "entmake and entget do not
have compatible argument/result lists".

I have mixed feelings about removing xdata, since there are equally valid reasons for protecting it as well as removing it. To wit, many of the programs I've written rely on the presence of xdata, be it placed and managed by my applications or third parties like Autoplant.

On the other hand, I've had clients specifically have me write lobotomy type applications -- to purge all xdata, dictionaries et al in order to sanitize 'intelligent' drawings for other purposes.

In either case I'd be very careful when shaking off xdata by deleting and recreating entities unless I fully appreciated all the ramifications of doing so, especially all the different means by which entity / object relationships exist, and subsequently can be broken.

Does Keith? In that I've no doubt.

Should the general viewing audience be warned? ABSOLUTELY.

So, if one knows what they're doing, this non destructive (in terms of retaining the original entity) may be of interest:

Code: [Select]

(defun _RemoveXdata ( ename appidlist / xdata )

    ;;========================================================
    ;;
    ;;  Caller's responsibility to ensure valid entity
    ;;  passed to function (including editable state)
    ;;
    ;;--------------------------------------------------------
    ;;
    ;;  Remove all xdata:
    ;;
    ;;      (_RemoveXdata ename '("*"))
    ;;
    ;;  Remove specific xdata, form 1:
    ;;
    ;;      (_RemoveXdata ename '("appid1,appid2"))
    ;;
    ;;  Remove specific xdata, form 2:
    ;;
    ;;      (_RemoveXdata ename '("appid1" "appid2"))
    ;;
    ;;  Remove wildcarded xdata:
    ;;
    ;;      (_RemoveXdata ename '("appid*"))
    ;;
    ;;========================================================

    (if (setq xdata (cdr (assoc -3 (entget ename appidlist))))
        (entmod
            (append
                (entget ename)
                (list
                    (cons -3
                        (mapcar
                           '(lambda (x) (list (car x)))
                            xdata
                        )   
                    )
                )   
            )
        )
    )
)

[TonyT]

Well, better late than never, eh Mike ?

Gentlemen, before this turns into a bit throwing contest I encourage you to make the attempts to speak to each other cordially and respectfully. Thank you.

[MP]

Hi Tony.

Just because some folks didn't comment on it doesn't mean that "everyone is confused about it".

But to be clear, without explicit properties included in the dxf group codes, entmake will adopt what is current, like cecolor et al, which can yield unexpected results.

Michael.

[MP]

Well, better late than never, eh Mike ?

Well I do have a life and commitments beyond this board.

[TonyT]

So, is this about my incorrect use of the word 'everyone', or
the incorrect and improper use of (entget) and (entmake) to
remove xdata, but do nothing else ?

Yes, Mike that's right, entmake adopts the current editor
properties, not the properties of the object whose entity
data was returned by entget, but that isn't removing xdata.
That is removing xdata and possibly changing properties of
the object.

And I won't even get into how it screws up field references,
draworder, and various other things that involve references
to other objects using handles.

Hi Tony.

Just because some folks didn't comment on it doesn't mean that "everyone is confused about it".

But to be clear, without explicit properties included in the dxf group codes, entmake will adopt what is current, like cecolor et al, which can yield unexpected results.

Michael.

[MP]

So, is this about my incorrect use of the word 'everyone', or ...

I was addressing the assumption / assertion that everyone is confused.

[TonyT]

Mike - Post warnings in reponse to posts that justify
the warnings, not in response to the response to it.

And I realize that you don't live in a bubble, but you
posted in the thread at the point when the warning
should have been posted, but wasn't.

Well, better late than never, eh Mike ?

Well I do have a life and commitments beyond this board.

[MP]

... you posted in the thread at the point when the warning  should have been posted, but wasn't.

Acknowledge.

[Kerry]

...........
What you fail to realize is that once "your" drawing is in my hands .. unless I am working for you, the presence of the data is of no consequence.
.............

Keith,

I probably won't care what you (or anyone) do with 'my' drawings { If they are issued for info only }

I do care about code you (or anyone) deliver to me which is supposedly designed to have a specific functionality but has the side effect of destroying my data.

[Keith™]

I do care about code you (or anyone) deliver to me which is supposedly designed to have a specific functionality but has the side effect of destroying my data.

But wasn't that the desired effect in the beginning? To destroy the data?

I think the tone of the topic has changed a bit from what it was meant to be to something entirely different.

Tony, just so we are perfectly clear .. the code above was not meant to be complete ... but rather a snippet of how something could be done ... that being, if you collect the entity list of an object, sans the xdata, then re-write that entity list directly without having to change it, the entity would be re-written and there would be no xdata attached.

You are correct that the new object could take on the properties set current, but only if they have not already been hard coded to something else. i.e. if a line has been hard coded to be red and you create that line using entmake, it will indeed be red, even if you have the current color property to something else.

With regards to your widget which requires an object enabler, I think perhaps you are being a little bit disengenuous, since without your program that created that object, it cannot be edited, copied or created, because AutoCAD does not know how to handle it. Therefore one could not possibly edit any widget for which they do not have the programming to do so with. Therefore in my example given above, I could not have created the a new widget using your custom object as a base. When I was refering to a widget, I was refering to any collection of native AutoCAD objects (i.e. lines creating a door or window) that can be edited to form another widget (i.e. a bolt, shelf or appliance). Perhaps the terms I chose were not clear enough to elicit the thought process I had hoped.

[Kerry]

Keith

Choose any entity.
Then add an XRecord for my data.
Then reference the entity from a field object.

Then put your Xdata on the entity.

added: then add an object reactor, just for the fun of it.

Now, delete your xdata, your way, and let us know what happens.

I do care about code you (or anyone) deliver to me which is supposedly designed to have a specific functionality but has the side effect of destroying my data.

But wasn't that the desired effect in the beginning? To destroy the data?

............

[Atook]

Wow, I'm surprised how hot this topic got.

I have to say I can see Keith's side of wanting to purge all extraneous data, and if he's using the file for his own purpose, it seems like a valid thing to do.

I would say that if a drawing that contains xdata is meant to go between agencies with said xdata preserved, then all parties involved should know that and protect the xdata appropriately. If someone runs Kieth's superpurge-deathtoallxdata.lsp on a drawing that they shouldn't have, then they are liable for it. There's nothing wrong with Kieth providing the tools for it. After all, lisp doesn't kill xdata, people do!

[Maverick®]

hi:
    please tell me how to delete xdata?

  Considering this was the original post.....  Pretty scarce on details but it sounds like Keith provided what OP wanted.  The warning is nice though.

  Kinda like someone asking "How do I remove Windows from my computer"?   

[Kerry]

Chuck Gabriel posted the solution the OP was looking for, it seems.

In VBA (and probably .NET as well) the method is to overwrite the xdata for the desired regapp name with a list that consists of nothing but the regapp info.
..............

it's ok.
thanks.

[Nathan Taylor]

Yep. In the correct Language and only doing what was asked without side effects.

Chuck Gabriel posted the solution the OP was looking for, it seems.

In VBA (and probably .NET as well) the method is to overwrite the xdata for the desired regapp name with a list that consists of nothing but the regapp info.
..............

it's ok.
thanks.

[ahsattarian]

I've seen the topic recently.

Dimensions also work with Xdata to save their properties changed by propertis toolbar, so we should be very caring deleting them.

Regards,  Amir