To understand all words from the incantation you need incantaion reference book. You are neither sorcerer nor digger nor shaman if you have no sorcery book! It seems to me that the most useful AutoLISP book is the book of famous authors Nikolay Poleshchuk and Peter Loskutov "AutoLISP and Visual LISP Inside AutoCAD". Lacking it I would be helpless. It is already so frayed that I am growing cold with horror from the idea that such books will be not published. It would be necessary to convert it into electronic form though it is unpolite to the respected wizards.

Room "ACAD_EVALUATION_GRAPH" contains doors into block dynamic parameters. Parameters of the dynamic block are not information, they are special tools using which you can twist statue eyes or move its legs or manage visibilty of its parts.

Here are doors to common halls. Sorcerers' tricks. There is a big hall and it has doors to less halls but from the majority of small halls there are doors to the common hall. While you are going, going, deeper and deeper and you see a door. And you want to enter. You are opening the door and again find yourself in the common hall from where your way has begun. If foolishly you shut the door (that is do not store its name in memory) then to return to previous room you should go all the way from the very beginning. Such a trick. Like in the game with bricks and chips moving along the line. At definite moment you can at one step return for several steps but you cannot do so in the forward direction. One way ticket.

User who does not wish to restrict himself only with lines drafting must appreciate values of dynamic block parameters. At the same time we have very thin box of instruments to control these parameters. There are many mystrious "immured" doors. Many possibilities never declared, and you feel some incompleteness. As if somebody was in a hurry, lacked time to do everything and immured doors to unfinished rooms.

There are different parameters. Some parameters stretch object, some of them move it, reduce or enlarge. Some parameters multipy object doing many copies of it. But the most interesting paraameters are (1) the parameter that makes some objects visible and some invisible depending on demands and (2) the parameter controlling all the other parameters. The forst parameter is called Visibility Set, and the second one is Lookup. The further talk will be connected with them.

Almost all the parameters have four appendices required for the work. Activator is a thing that connects parameter with the object. Grip is another thing that we see as a cyan triangle in the model and with which we can pull the block. Two invisible and strange devices that define grip position in model or paper space.

I have written "almost" because Visibility Set is the only parameter that does not require activator. It is a parameter and an activator in one wrapper.

This is a content of the room "ACAD_EVALUATION_GRAPH" if block has only one Visibility Set parameter:
((-1 . <Entity name: 7efdd0d8>)
(0 . "ACAD_EVALUATION_GRAPH")
(5 . "11B")
(102 . "{ACAD_REACTORS") (330 . <Entity name: 7efdd0d0>) (102 . "}")
(330 . <Entity name: 7efdd0d0>)
(100 . "AcDbEvalGraph")
(96 . 4)
(97 . 4)
(91 . 0) (93 . 32) (95 . 1) (360 . <Entity name: 7efdd0e8>) (92 . 0) (92 . 0) (92 . 1) (92 . 2)
(91 . 1) (93 . 32) (95 . 2) (360 . <Entity name: 7efdd0f0>) (92 . -1) (92 . -1) (92 . 0) (92 . 0)
(91 . 2) (93 . 32) (95 . 3) (360 . <Entity name: 7efdd0f8>) (92 . 1) (92 . 1) (92 . -1) (92 . -1)
(91 . 3) (93 . 32) (95 . 4) (360 . <Entity name: 7efdd100>) (92 . 2) (92 . 2) (92 . -1) (92 . -1)
(92 . 0) (93 . 0) (94 . 1) (91 . 1) (91 . 0) (92 . -1) (92 . -1) (92 . -1) (92 . -1) (92 . -1)
(92 . 1) (93 . 0) (94 . 1) (91 . 0) (91 . 2) (92 . -1) (92 . -1) (92 . -1) (92 . 2) (92 . -1)
(92 . 2) (93 . 0) (94 . 1) (91 . 0) (91 . 3) (92 . -1) (92 . -1) (92 . 1) (92 . -1) (92 . -1))

<Entity name: 7efdd0e8> - äâåðü â "BLOCKVISIBILITYPARAMETER".
<Entity name: 7efdd0f0> is a door to "BLOCKVISIBILITYGRIP".
<Entity name: 7efdd0f8> is a door to "BLOCKGRIPLOCATIONCOMPONENT" "UpdatedX".
<Entity name: 7efdd100> is a door to "BLOCKGRIPLOCATIONCOMPONENT" "UpdatedY".

Here we see parameter itself and two objects that define X and Y position of the grip.

An extract from my theme (Russian) in the Internet (children may not read this):

...
I think that up to code 96 it is unnecessary to describe dotted pairs as long as AutoLISP books contain much information on them.

[Aha, but with reservation "almost".]

As yet codes 96 and 97 we will not consider for one can't understand them without knowing all.
Since Autodesk provides neither structure description nor used terms we will invent ours. If somebody does not like my terms then suggest yours.
So:
Apart from separate dotted pairs located in the beginning of the list and holding general definition of name, object type, handle etc. all the rest can be divided into "records". I call "record" a sentence of dotted pairs describing some constant. Record begins after code 97 from the dotted pair with ordinal number of record. This is code 91. Records are marked from 0.
Sample
(91 . 0) (93 . 32) (95 . 11) (360 . <Entity name: 7bf53308>) (92 . 0) (92 . 0) (92 . 1) (92 . 2)
Next pair with code 83 is a record type. Ther are some other records in the same dictionary and other dictionaries too and AutoCAD probably in his depths has a set of functions that depending on record type know how many dotted pairs are in it, at what places and with what meaning, namely these functions process records.
Next code is 85, it is a number of element creation sequence. That is when element is being created it gets next number. You cannot change this number for immediate fatal error. It accompanies code 360. It does not affect the sequence of block properties display.
Next code 360 is object's name. It is either ...PARAMETER, or ...GRIP, or BLOCKGRIPLOCATIONCOMPONENT, or ...ACTION. You see them in the block editor window. Though there are evidently seen only parameters and activators but there are grips too (cyan triangles). BLOCKGRIPLOCATIONCOMPONENT as I have alreaday written is an object with grip position data.
Next code 92 (it is a first one in the line of codes 92) is object number in the hierarchy dependence-belonging or in other words place marker in the family tree. I think that even schoolchildren know what the family (genealogy) tree is and how it looks like. In the ...ACTION object code 92 points to the second record of the first chain control parameter's extended data.
Next code 92 (it is a second one in the line of codes 92) is additional (second) place marker. It is used for pointing to "adopting" parent, that is generally ...ACTION. The main parent is always ...GRIP. If object has no ACTION then the first and the second pairs with codes 92 are equal. That is they have the same code.
In the ...ACTION object (in the case of controlling parameters chain) it points to the second record of the last chain controlled parameter extended data.
Next code 92 (it is a third one in the line of codes 92) is a pointer to a child component No. 1. If this pair belongs to ...PARAMETER element then it is a pointer to a child component "UpdatedX", i.e. X position. For ...GRIP or ...ACTION element the pair points to a child component ...PARAMETER.
Next code 92 (it is a fourth one in the line of codes 92) is a pointer to a child component No. 2. If this pair belongs to ...PARAMETER element then it is a pointer to a child component "UpdatedY", i.e. Y position. For ...GRIP or ...ACTION element the pair points to a child component ...PARAMETER.
LOOKUP object is an exclusion, in the case of LOOKUP chain this dotted pair points to continuation of extended record and there - to component "UpdatedY".
For ...GRIP and ...ACTION the two last codes 92 are always equal and point to the same thing.
If dotted pair includes -1 it means that this pair contains no information on belonging.
After all the properties description end by records (93 . 32) there follow records (93 . 0) which are extended data on belonging of elements to each other. These records are tied to main records by code for marker of position in the family tree.
Sample:
(92 . 0) (93 . 0) (94 . 1) (91 . 1) (91 . 0) (92 . -1) (92 . -1) (92 . -1) (92 . -1) (92 . -1)
(92 . 1) (93 . 0) (94 . 1) (91 . 0) (91 . 2) (92 . -1) (92 . -1) (92 . -1) (92 . 2) (92 . -1)
(92 . 2) (93 . 0) (94 . 1) (91 . 0) (91 . 3) (92 . -1) (92 . -1) (92 . 1) (92 . -1) (92 . -1))
The first code 92 is a pointer to marker of an element (it is first or second dotted pair in the line of four dotted pairs). It says that the record just belongs to this element.
The second code 93 is a record type.
The third code 94 - I do not know. It is always 1.
Next two codes 91 follow.
The first one is a pointer to the number of the parent element record 32.
The second one is a pointer to the number of its own record 32.
Next five codes 92 follow.
The first one is a pointer to the main element record marker. It's dotted pair of the first code 92 in the element that extended record belongs to. In additional extended data (second record) it points to additional extended data of the previous element in the chain.
The second one is a pointer to the additional element record marker. It's dotted pair of the second code 92 in the element that extended record belongs to. If there is no such element then it is -1. In additional extended data (second record) it points to additional extended data of the next element in the chain.
The first and the second dotted pairs with code 92 are being filled with values only when there is "adopting" parent, that is ...PARAMETER has connection with ...ACTION element. In the rest cases both pairs are always -1.
The third one:
- in extended record "UpdatedY" it is a pointer to "UpdatedX" connection;
- in extended record "Lookup" it is a pointer to extended data of the previous Lookup in the chain (see later).
The fourth one:
- in extended record "UpdatedX" it is a pointer to "UpdatedY" connection;
- in extended record "Lookup" it is a pointer to extended data of the next Lookup in the chain (see later).
In the rest extended records the 3rd and 4th code is always -1 (anyhow I have not found other data).
The fifth one:
- in the case of chain it points to previous or next record of additional extended data (2nd record).
BLOCKVISIBILITYPARAMETER has no ACTION. At all. Only GRIP and two BLOCKGRIPLOCATIONCOMPONENTs.
...GRIP has no extended data and values of the first two codes 92 in the record 32 are always -1

Where did I know it from? From nowhere. All alone I sat many days. Nobody wanted to climb here with me. I touched everything with my hands many times. A couple of times I got in Fatal Error. But "sheepskip was worth currying" (it was very useful, Russian).

Previous | Next

NP CAD Page | Articles || Introduction | 1 | 2 | 3 | 4 | 5 | 7 | 8 | 9 | 10 | 11 | 12 || Russian