Topic: Dictionary project

[T.Willey]

You wouldn't make me mad by using LData, but I wouldn't be able to help since I have never used it since I read those posts.  My thinking was better safe than sorry, and since I can code it in another way without any rick of problems, then that is the way I would want to go.  To each their own, and I hope you have no problems with LData.

[Arch_Eric]

Here is my working code, Daron. Run DAREA and select ParentAdd. Click your text object to hold the total, choose whether it's a sum (sum of other text objects) or area (area of polylines) object, then select each child object. ParentDelete deletes all links to the parent object, ChildDelete deletes a single link. ChildAdd adds a single link to an existing parent. Cleanup checks for deleted objects and removes their links.

DISCLAIMER: This code uses LDATA functions and may or may not cause problems. Use at your own risk. See above posts.

[daron]

Thanks.

[jbuzbee]

LData:

Luis E. and I did extensive testing of Ldata back in the day.  Some of the more heinous side effects were corruption of collections, and vertical application collections (specifically ADT).  What was apparently happening, if say a block had ldata attached to it, there was a strong possibility for the Blocks collection to become corrupted.  It was severe in the Vertical application collections (ADT WallStyles, etc.) because these "collections" are defined in AEC_ dictionaries. 

I don't know the how, I don't know if it's been fixed, but I had to reconstitute a major part of an architectural project I was working on due to LData.  I'll never use it again.

[T.Willey]

LData:

Luis E. and I did extensive testing of Ldata back in the day.  Some of the more heinous side effects were corruption of collections, and vertical application collections (specifically ADT).  What was apparently happening, if say a block had ldata attached to it, there was a strong possibility for the Blocks collection to become corrupted.  It was severe in the Vertical application collections (ADT WallStyles, etc.) because these "collections" are defined in AEC_ dictionaries. 

I don't know the how, I don't know if it's been fixed, but I had to reconstitute a major part of an architectural project I was working on due to LData.  I'll never use it again.

Thanks for sharing you experience James.  Another reason I'm glad I never tried ldata.

[hermanm]

I've only used ldata to store drawing specific variables, in a dictionary owned by named object dictionary, and only in "recent" versions of AutoCAD.

In that context, I have experienced no difficulties with ldata.

As regards access to ldata from other programming environments,

http://discussion.autodesk.com/thread.jspa?messageID=5896693

[T.Willey]

I've only used ldata to store drawing specific variables, in a dictionary owned by named object dictionary, and only in "recent" versions of AutoCAD.

In that context, I have experienced no difficulties with ldata.

As regards access to ldata from other programming environments,

http://discussion.autodesk.com/thread.jspa?messageID=5896693

Thanks for sharing your good experience, as we need both sides.

[Arch_Eric]

I found a library of functions (vlax-ldata.lsp) to replace LData functions that function exactly the same way, except they use XRecords. So there shouldn't be any problems with it. So I replaced my function calls and everything works. Now I'm working on my reactor, and I've run into a problem that has stumped me.

When I make a change to my polyline, it calls the recalc function and all my totals update. If I undo the change, it errors out in the recalc function, even though it's calling the same function. Its in the inside foreach loop that gets the area of the polylines. When it calls the vlax-curve-getarea function, it comes back saying my variable is empty. I check the list object that foreach calls and it's got data. Doesn't make sense...

[CAB]

Eric,
I would like to mention a few things.
 (vl-load-com) need only be executed once per DWG session so place it in the lisp file so that
 when the lisp is loaded it will get it done once.
 
 (setvar "cmdecho" 0) only comes into play when you use a COMMAND or vl-cmdf so there is no need for it.
 
 One last thing. The While loop can use a progn so your code can be modified to this.

Code: [Select]

(defun c:darea (/ darea-option)
  (setvar "cmdecho" 0)
  (princ "\n*** DYNAMIC AREA ***")
  (while
    (progn
      (initget "PAdd PDelete CAdd CDelete List CLeanup Recalc")
      (setq darea-option
             (getkword
               "\n[ParentAdd/ParentDelete/ChildAdd/ChildDelete/List/CLeanup/Recalc] <Exit>: ")))
     (cond
       ((= darea-option "PAdd") (ld-addparent))
       ((= darea-option "PDelete") (ld-delparent))
       ((= darea-option "CAdd") (ld-addchild))
       ((= darea-option "CDelete") (ld-delchild))
       ((= darea-option "List") (ld-listchildren))
       ((= darea-option "CLeanup") (ld-cleanup))
       ((= darea-option "Recalc") (ld-recalc nil nil nil))
     )
  )
  (princ)
)

[daron]

Even if you do continue to use it, save the users initial settings to a variable so you can return it to them later. Yes, you only have a 50/50 chance, but what if the user likes cmdecho set to 0. Let the computer decide what to set it back to. Also with the idea of reactors and I'm not sure if this will be an issue here, but (vla-regen (vla-get-activedocument (vlax-get-acad-object)) acAllViewports) will keep you away from using command in this case. Just be sure and set your vla objects to a variable for later clearing.

[CAB]

Eric,
  You can also replace (command "regen") with
  (vla-regen (vla-get-activedocument (vlax-get-acad-object)) acactiveviewport)
  or as Daron suggested
  (vla-regen (vla-get-activedocument (vlax-get-acad-object)) acAllViewports)

Daron beat me to it.

PS looks like you have the regen in each sub function so no need to include it in the main routine.

[Arch_Eric]

Thanks for the pointers guys. I was starting to look for a replacement for calling Regen with command.