Using (append) vs. (subst) to change entity data

[Kent1Cooper]

Not a question, but a piece of potentially useful information....

I was working on something to change "optional" entity data entries [those which may or may not be present], such as the one for entity color.  In the case of something whose color is Bylayer, there is no 62-code color entry in the entity data list, and if you want to change it to [for instance] red, you can use (append) to add (62 . 1) to the list.  All is well.

Then I thought of the possibility that an entity might already have an override color, and that I might need to use (subst) instead of (append), to replace rather than add the color value.  But I didn't relish the idea of checking whether it has one, to determine whether to use (subst) vs. (append).  [I thought of using (vla-put-color), which wouldn't care, but didn't have any other reason to convert the entity to a vla-object, and because of what the routine does, would have needed to do that to two entities just to change one of them, so I was hoping to avoid that step.]

So I did some experimenting, and found that you can still use (append) to put an entry at the end of the list, and it will take precedence over the other entry with the same code number, earlier in the list!

For instance, I drew a Circle and gave it override color 1 (red).  Excerpts of the entity data, showing the 62-code entry with the 1 for red color:

Command: (setq edata (entget (entlast)))
(... (0 . "CIRCLE") ... (8 . "0") (62 . 1) (100 . "AcDbCircle") ...)

Then I tried updating the color to cyan [4] using (append), not using (subst), and got this list:

Command: (setq edata (append edata '((62 . 4))))
(... (0 . "CIRCLE") ... (8 . "0") (62 . 1) (100 . "AcDbCircle") ... (210 0.0 0.0 1.0) (62 . 4))

The list contains both 62-code entries, the original in the usual place and the new one at the end.  That's what I expected in what (append) returns, but even after doing (entmod edata), they're still both in the list.

But the color of the Circle on-screen does change to cyan, and when I do (entget) on it again, I get:
 

(... (0 . "CIRCLE") ... (8 . "0") (62 . 4) (100 . "AcDbCircle") ...)

with only the one 62-code entry, in the usual location but with the new color.  It appears an entity data list can have more than one entry for the same piece of information, and if it does, the later one seems to "win out" over the earlier one.

So I've gone ahead and written the routine with only (append) for that optional-entry-updating purpose, and it works using only that one function, whether or not there's already an entry for that information in the entity data list.  This avoids the need to check for that.

I just thought someone might like to know that, because it was a surprise to me, and a code-saver.

[markruys2]

excellent observation, but we will have to test on multiple versions of autocad,

which version are u using?

thanks

m

[Kent1Cooper]

---

@markruys2 wrote:

....we will have to test on multiple versions of autocad,

which version are u using?

....

---

I'm back here in 2004.  Since entity data lists are so fundamental, I wouldn't expect something like this to change, but I'm ready to be surprised.

[t.willey]

In the later versions I have noticed that the order of some codes matter ( my instance was working with attributes in blocks ).  I had to change one routine when I got to '09 because of this issue.  So I would use the check if it's there, then use either subst or append as needed.