With AutoLISP/Visual Lisp and DCL there is a list indexing problem.
Given ("A" "B" "C") in one drawing session it's easy enough to use
nth, i.e. take the integer value of the DCL tile (such as (atoi "1") for "B")
to locate the item.
But when content changes, or is passed among other drawings, this
does not work very well for me. I've noticed the same problem in CLOS.
In VLisp I came up with the following solution to my problem:
(defun :msp:index-list (given / ix)
;;[dfn] :msp:index-list Given a list, cons w/indexes for association. ;;
;;[ii>] ("A" "B" "C")
;;[ii<] (("A" . 0)("B" . 1)("C" . 2))
(setq ix -1)
(mapcar (function (lambda (x) (cons (setq ix (1+ ix)) x))) given))
(defun :msp:index-cdr (given)
;;[dfn] :msp:index-cdr Given a list, cons w/indexes for association. ;;
;;[ii>] ("A" "B" "C")
;;[ii<] ((0 . "A")(1 . "B")(2 . "C"))
(mapcar (function (lambda (x) (cons (cdr x) (car x))))
(:msp:index-list given)))
I'm sure there are either better solutions, or even no need for one at all...
If I pull the source list into memory and order it in the same way that I
order Dialog-List-1, then the indexes will always match. But if I use
the drawing itself for the source I cannot control the list order without
resorting to extra code that might be interesting to write, but otherwise
useless for my purposes. One of my "object-like" contraptions has over
one hundred properties, so a drawing with one hundred of these would
have ten thousand slots in it, which is not necessary. All I need is one
hundred slots refering me to the "object" selected so that I can pull its
properties into Dialog-List-2, etc.