Function Entry: ENTMOD

← Prev | ↑ Chapter | Next → | Index | Symbols

Function Entry: ENTMOD

Name

entmod

Class

Host Function

Syntax

(entmod elist)

Arguments and Values

  • elist: entity definition association list

Autodesk documents that the entity name to modify is taken from group -1 in elist.

Description

Modifies an entity in the drawing database according to the supplied entity definition list.

Return Values

List or nil.

If successful, Autodesk documents that entmod returns the supplied elist; otherwise it returns nil.

Side Effects

Modifies the drawing database.

Exceptional Situations

Erroneous if the entity definition list is invalid or requests an illegal modification.

Compatibility

Semantically paired with entget.

Availability

  • AutoCAD 2026: documented (per Autodesk reference page).
  • BricsCAD V26: presumed compatible (no contradicting page found).
  • Status: AutoCAD documented; BricsCAD presumed-both pending Phase 4 verification.

Notes

  • Autodesk documents that an entity's type and handle cannot be changed.
  • Autodesk documents that certain internal fields, such as the -2 group of a SEQEND, are ignored if modified.
  • Autodesk documents that viewport entities cannot be modified with entmod.
  • Autodesk documents that changing entities inside a block definition affects all inserts of that block.
  • Autodesk documents special color behavior in AutoCAD 2004 and later: if true-color group 420 conflicts with ACI group 62, the true-color value takes precedence.

clautolisp

entmod replaces the entity's ordinary group codes with the supplied ones (the handle and type are preserved; the -1~/~5 pairs are ignored), and edits extended data per application: an (-3 ("APP" …)) group with pairs replaces that application's xdata, one with no pairs removes it, applications not mentioned are preserved, and an entmod whose list carries no (-3 …) group leaves existing xdata untouched. A list naming no live entity returns nil and sets ERRNO 2; no Common-Lisp condition is raised.

Non-graphical objects (resolved divergence — chapter 25 case 2)

entmod on a non-graphical object — an XRECORD or DICTIONARY entry (AcDbObject, not AcDbEntity) — does not modify the object's contents. This is the normative behaviour of this specification, adopted from AutoCAD, whose reference states it explicitly: "Dictionary objects can be examined with entget and their xdata modified with entmod. Their entries cannot be altered with entmod." (and lists AcDbXrecord among the objects entmod does not support). Such objects are edited through the object protocol (vlax-put) or the dictionary functions (dictadd, dictremove), not entmod. Only the object's xdata (-3) is editable by entmod.

BricsCAD's reference and product take the opposite position — it documents entmod on "an object or entity" with no carve-out and applies the change to an XRECORD. This specification recognises that divergence but does not condone it: the lack of an AutoCAD-style restriction in the BricsCAD documentation, and the resulting silent mutation of dictionary-entry contents, is treated as a non-portable vendor deviation, not as normative AutoLISP.

Per dialect (chapter 25, resolved divergence):

  • --dialect autocad-2026, --dialect clautolisp, and --dialect strict — the normative behaviour: entmod on a non-graphical object is a no-op (returns nil, contents unchanged). strict additionally emits the [entmod-nongraphical] warning; the others are silent.
  • --dialect bricscad-v26 — reproduces BricsCAD's application of the change and emits the [entmod-nongraphical] warning (the non-condoned deviant dialect).
  • --lax — applies the change, silently.

entmod on a graphical entity is unaffected under every dialect.