Topic: Lists in extended data

[curmudgeon]

Trying to understand the utility of (1002 . "{").

Code: [Select]

(setq ent (entget (car (entsel) ) '("RAK")))
(setq ylist (list (list -3 (list "RAK" (cons 1002 "{")  (cons 1070 2) (cons 1002 "}")))))
(entmod (append ent ylist))
(setq ent (entget (car (entsel) ) '("RAK"))

(member '(1002 . "{") (cdadr (assoc -3 ent)))
returns

Code: [Select]

((1002 . "{") (1070 . 2) (1002 . "}"))
What I am wanting - as a place to start - is to simply record electrical data like WATTS and PHASE.
In such an uncomplicated scheme, I could just as easily

Code: [Select]

(setq ylist (list (list -3 (list "RAK"      
      (cons 1000 "watts") (cons 1070 180)
      (cons 1000 "phase") (cons 1070 1)      
)
  )
    )
)
and preserve a description with the numerical data.

BUT I AM JUST BEGINNING.
Is there some reason to include the (1002 "{) ?

[Lee Mac]

The groups (1002 . "{") and (1002 . "}") are primarily used to group sets of DXF data, for example, if your data were to contain multiple sets of the 'watts' & 'phase' DXF groups, you could implement the DXF groups 1002 in the following way:

Code - Auto/Visual Lisp: [Select]

1. (
2.     "RAK"
3.     (1002 . "{")
4.         (1000 . "watts")
5.         (1070 . 180)
6.         (1000 . "phase")
7.         (1070 . 1)
8.     (1002 . "}")
9.     (1002 . "{")
10.         (1000 . "watts")
11.         (1070 . 200)
12.         (1000 . "phase")
13.         (1070 . 2)
14.     (1002 . "}")
15. )
16.  

Aside from the readability benefits for those visually inspecting the xdata, by grouping & structuring the data using known delimiters, this method ensures that the xdata is parsed accurately and consistently.

For example: assume that the data is not grouped using 1002 delimiters and that, by chance, one of the DXF groups is missing from the data.

Now, when the xdata is parsed, the parsing function is relying on a known order of the xdata DXF groups and also a predetermined number of groups in each set. If only one of the expected DXF groups is missing for some reason, a pair from the next set of DXF groups will be erroneously included in the wrong set, rendering the data useless.

Whereas, if the xdata is consistently grouped using DXF group 1002 codes, any parsing function can use these groups as fixed delimiters indicating where one set of xdata ends and the next begins, and hence ensuring that the data is grouped accurately every time, even if data is missing for any reason.

Of course, for a single data set (as per your example), this is not strictly necessary, however, I would still recommend including the 1002 DXF groups for both consistency with how AutoCAD inherently stores xdata, and to allow for any future expansion of the data without the need to restructure the existing data or to rewrite the xdata parsing function.

There may be other advantages to using the DXF 1002 groups that I have overlooked, but in my opinion, the above points are sufficient to warrant their use.

Lee

[curmudgeon]

Thank you Lee. Exactly what I was wanting, and I can give you a good example.
They added the group code (90 . 0) to my LWPOLYLINE, and I was using position at times.
This was NOT xdata, but the same kind of consideration.

Again, thanks.

roy

[curmudgeon]

and to store a symbol in xdata....

Code: [Select]

(set 'b 180)
(setq ylist (list (list -3 (list "RAK"      
      (cons 1000 "watts") (cons 1000 "b")
      (cons 1000 "phase") (cons 1070 1)      
)
  )
    )
)
...
(eval (read "b"))
returns 180

save a variable to xdata.
onward.

[Lee Mac]

You're most welcome roy 

and to store a symbol in xdata....

Code: [Select]

(set 'b 180)
(setq ylist (list (list -3 (list "RAK"      
      (cons 1000 "watts") (cons 1000 "b")
      (cons 1000 "phase") (cons 1070 1)      
)
  )
    )
)
...
(eval (read "b"))
returns 180

I would note that since your data contains no expressions to be evaluated and is 'literal', you can improve the efficiency & readability (in my opinion, anyway) of the code by quoting the literal expressions, e.g.:

Code - Auto/Visual Lisp: [Select]

1. (setq ylist
2.    '(
3.         (   -3
4.             (   "RAK"
5.                 (1000 . "watts")
6.                 (1000 . "b")
7.                 (1000 . "phase")
8.                 (1070 . 1)
9.             )
10.         )
11.     )
12. )

However, I am uncertain as to why you would wish to store a variable symbol in xdata over the value held by such symbol, since the symbol will be undefined outside of the namespace in which it is defined (e.g. after the drawing is closed).

[curmudgeon]

I would have used different words - but yes, putting a certain piece of text into xdata and later retrieving it MIGHT be a clever trick, if in some way it made the "application" work better.

I DO NOT have such an application in mind, just playing with it, conceptually.

And yes, I understand why you format your code as you do. I will endeavor to remember that.
Thanks.