An application can call entget to obtain the xdata that it has registered. The entget function can return both the definition data and the xdata for the applications it requests. It requires an additional argument, application, that specifies the application names. The names passed to entget must correspond to applications registered by a previous call to regapp; they can also contain wild-card characters.
By default, associative hatch patterns contain extended data. The following code shows the association list of this xdata.
Command: (entget (car (entsel)) '("ACAD"))
Select object: Select an associative hatch
Entering the preceding code at the command line returns a list that looks something like this:
((-1 . <Entity name: 600000c0>) (0 . "INSERT") (8 . "0") (2 . "*X0")
(10 0.0 0.0 0.0) (41 . 1.0) (42 . 1.0) (50 . 0.0) (43 . 1.0) (70 . 0) (71 . 0)
(44 . 0.0) (45 . 0.0) (210 0.0 0.0 1.0) (-3 ("ACAD" (1000 . "HATCH")
(1002 . "{") (1070 . 16) (1000 . "LINE") (1040 . 1.0) (1040 . 0.0)
(1002 . "}"))))
This fragment shows a typical sequence for retrieving xdata for two specified applications. Note that the application argument passes application names in list form:
(setq working_elist
(entget ent_name
'("MY_APP_1" "SOME_OTHER") ; Only xdata from "MY_APP_1"
) ; and "SOME_OTHER" is retrieved.
)
(if working_elist
(progn
... ; Updates working entity groups.
(entmod working_elist) ; Only xdata from registered
) ; applications still in the
) ; working_elist list are modified.
As the sample code shows, you can modify xdata retrieved by entget by using a subsequent call to entmod, just as you can use entmod to modify normal definition data. You can also create xdata by defining it in the entity list passed to entmake.
Returning the extended data of only those applications specifically requested protects one application from corrupting another application's data. It also controls the amount of memory that an application needs to use and simplifies the xdata processing that an application needs to perform.