How to copy a dictionary from one entity to a new one?

How to copy a dictionary from one entity to a new one?

nwbos
Enthusiast Enthusiast
859 Views
8 Replies
Message 1 of 9

How to copy a dictionary from one entity to a new one?

nwbos
Enthusiast
Enthusiast

We've build a lisp code to replace imported Arcgis points to the correct cad block defined by our national standard.

 

We do this by creating a new block using entmake:

(setq $entList (list 
                '(0 . "INSERT")
                (cons 2 $bname)
                ;  (cons 8 $lName)
                (assoc 8 $entSelect)
                (cons 10 $inspt)
                (cons 41 1)
                (cons 42 1)
                (cons 43 1)
                (cons 50 (* $rotang (/ pi 180)))
                (assoc 210 $entSelect)
                '(102 . "{ACAD_XDICTIONARY")
                (assoc 360 $entSelect)
                '(102 . "}")
             )
)

(setq $entityName (entmake $entList))
 
all the properties added correctly, except for the "ACAD_XDICTIONARY"  with assoc 360
 
What are we missing?  any ideas? 
0 Likes
Accepted solutions (1)
860 Views
8 Replies
Replies (8)
Message 2 of 9

marko_ribar
Advisor
Advisor

Post a sample DWG with (some) point(s) that have dictionary data assigned, and DWG with your block you are trying to replace point(s) with.

Marko Ribar, d.i.a. (graduated engineer of architecture)
0 Likes
Message 3 of 9

nwbos
Enthusiast
Enthusiast

it's a question about function defined on line 752. Block replacement works fine. But on line 930, 931 en 932 we want to add te dict from the points. If i print $entList it shows the values in console. But when put in entmake it doesnt contain the data.

0 Likes
Message 4 of 9

marko_ribar
Advisor
Advisor

I don't know how to help you for now... Your layer on which points reside is somehow unaccessable for other entities than points that are in it... Maybe its due to its name which is with "*" in front and proceeds with long description and it don't behaves like ordinary layers... It is also frozen and doesn't have XDICTIONARY reference like layer "0", so this is only thing that is somewhat usual, but else is very strange... I suppose that it was created by some other process and not in ordinary way ACAD creates layers... All I could do it thaw it, and points that are in it couldn't change layer to something different... You can also see that when you copy point, it automatically gets those XDICTIONARY entry different than source point... So something with this layer IMHO is preventing other objects to inherit its properties including your blocks from points XDICTIONARY - it's reserved only for points that were generated inside it... I've noticed that you placed wrongly (ssget) filter in your posted lisp - should have '(8 . "*ESRI...) - "*" in front was missing... Yes, blocks are generated, but their layername wasn't inherited from points too, beside not obtaining XDICTIONARY data... I don't know for now, further investigations are needed...

This simple code is for thawing points layer, but nothing else, so it's pretty useless - only for researching tasks it may be perhaps good...

 

(defun c:thaw-pts-layer ( / ss lay i e ex )
  (setq ss (ssget "_X" '((0 . "POINT"))))
  (setq lay (tblobjname "LAYER" (cdr (assoc 8 (entget (ssname ss 0))))))
  (entmod (subst (cons 70 0) (assoc 70 (entget lay)) (entget lay)))
  (repeat (setq i (sslength ss))
    (setq e (ssname ss (setq i (1- i))))
    (setq ex (entget e))
    (setq ex (subst (cons 8 "Defpoints") (assoc 8 ex) ex))
    (entupd (cdr (assoc -1 (entmod ex))))
  )
  (princ)
)
Marko Ribar, d.i.a. (graduated engineer of architecture)
0 Likes
Message 5 of 9

nwbos
Enthusiast
Enthusiast
Accepted solution

on the post CadTutor Roy_043 give us the insight to solve the problem. Two entities cannot reference the same extension dictionary. Do only thing I changed is order in the loop from:

-Collect data from the point -> entmake new block -> delete point

to

-Collect data from the point -> delete point -> entmake new block

0 Likes
Message 6 of 9

marko_ribar
Advisor
Advisor

Yes, XDICTIONARY is inherited, but source layer "*ESRI..." isn't... If that doesn't borther you, it's all fine, I hope...

Marko Ribar, d.i.a. (graduated engineer of architecture)
0 Likes
Message 7 of 9

marko_ribar
Advisor
Advisor

Futher more, I can't find a way how to get rid of damned "*ESRI..." layer where points were placed... (ssget "X" '((8 . "*ESRI..."))) is empty, but still maybe there are some things (ssget) can't find/select... I've noticed that there are some proxy entities in DWG... Maybe those should be removed too... There are some plugins for that on Exchange Apps site, but never tried...

Marko Ribar, d.i.a. (graduated engineer of architecture)
0 Likes
Message 8 of 9

nwbos
Enthusiast
Enthusiast

The *ESRI layers are needed for return the proces. When after edited by engineers(they are used to our national CAD standards) we can convert it back to ESRI layers. After that we can use the ESRI plugin again to write changes back to our GIS system.

0 Likes
Message 9 of 9

marko_ribar
Advisor
Advisor

@nwbos wrote:

The *ESRI layers are needed for return the proces. When after edited by engineers(they are used to our national CAD standards) we can convert it back to ESRI layers. After that we can use the ESRI plugin again to write changes back to our GIS system.


Nevertheless, layer(s) that aren't referenced by some other DWG, or something else, and are different than main "0" layer and can't be deleted, purged or removed by any known action are "BAD" layer(s) IMHO...

After whole procedure with engineers and other persons involved in project is finished, it would be best if sufficient stuff are removed and purged in order to make project more usable in some other situations that may arise in near or distant future...

You may agree or not, but those are the facts, not just my remarks. If you tend to leave project(s) always in working process and don't optimize each phase, final result could carry data that may be potential source(s) of confilicts if informations are superponing or memory is overloaded...

Further more, you would be forced to work slow and unefficient if size of DWG file or other used files are unusually big, or carry data that are not needed in work so that even small intervention(s) may cause instability, errors, crashing, difficulties, waste of time and loosing data in unpredicted ways that may occur making working process problematic and project unfinished or badly done...

So, consider that removing things like harmful stuff or strange unusual elements in some process or project is not a bad, but good approach and may give you and others more benefits than lacks... This could speed things and make situations more predictable and user friendly allowing things to be quickly improved, problems and dificulties overcomed giving better results, correct and healthy implementation and projects successfully done and finished.

Marko Ribar, d.i.a. (graduated engineer of architecture)
0 Likes