Author Topic: The future of DXF codes?  (Read 8709 times)

0 Members and 1 Guest are viewing this topic.

CAB

  • Global Moderator
  • Seagull
  • Posts: 10401
The future of DXF codes?
« on: April 12, 2004, 11:19:41 PM »
It was news to me...
URL
I've reached the age where the happy hour is a nap. (°Ώ°)
Windows 10 core i7 4790k 4Ghz 32GB GTX 970
Please support this web site.

SMadsen

  • Guest
The future of DXF codes?
« Reply #1 on: May 25, 2004, 07:03:56 AM »
Still waiting for Michael Puckett to provide the list of unsupported DXF codes ...

While waiting, can someone compile a list of properties that are unsupported by ActiveX and only available through DXF?  :)

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
The future of DXF codes?
« Reply #2 on: May 25, 2004, 07:08:58 AM »
Code: [Select]
(setq view_name "Section_A")
(setq viewbit (cdr (assoc 70 (tblsearch "view" view_name))))

which returns an integer to reflect the VIEW space location and/or xref info.
ie From the Group 70 code the following can be determined.
Standard flag values (bit-coded values):
1 = If set, this is a paper space view
16 = If set, table entry is externally dependent on an xref
32 = If both this bit and bit 16 are set, the externally dependent xref has been successfully resolved
64 = If set, the table entry was referenced by at least one entity in the drawing the last time the drawing was edited. (This flag is for the benefit of AutoCAD commands. It can be ignored by most programs that read DXF files and need not be set by programs that write DXF files)

I can find no way to do this with ActiveX
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

SMadsen

  • Guest
The future of DXF codes?
« Reply #3 on: May 25, 2004, 07:39:17 AM »
.. seems the list is taking form. Nice example, Kerry.
I can't see how to determine space or xref dependency for views, either.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
The future of DXF codes?
« Reply #4 on: May 25, 2004, 08:04:26 AM »
Quote from: SMadsen
Still waiting for Michael Puckett to provide the list of unsupported DXF codes ...
?

Did I miss a post?

I don't have a definitive list, though I suppose one could be hacked together; yet another interesting pet project, hmmm.

Right now my task is to get ready for work, cheers.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Keith™

  • Villiage Idiot
  • Seagull
  • Posts: 16899
  • Superior Stupidity at its best
The future of DXF codes?
« Reply #5 on: May 25, 2004, 08:20:25 AM »
do it then
Proud provider of opinion and arrogance since November 22, 2003 at 09:35:31 am
CadJockey Militia Field Marshal

Find me on https://parler.com @kblackie

SMadsen

  • Guest
The future of DXF codes?
« Reply #6 on: May 25, 2004, 08:25:34 AM »
Michael, I was referring to your statement "Which ones would you like me to list?" in reply to a question by CAB on the NG's.

More to the point, though, in my own peculiar way I was saying that I don't believe for one moment that the DXF scheme will be replaced by ActiveX unless Adesk will stop supporting AutoLISP.

Sure, not everything has been properly ported from one interface to another but I don't take that as a signal of discarding one of the interfaces. But then, only Adesk has an answer to it and they're not really known for spilling the(ir) beans.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
The future of DXF codes?
« Reply #7 on: May 25, 2004, 07:54:05 PM »
Ahhh, took me awhile but I found the thread. I have to apologize - I never answered the request for "all of them". Hmmm. As I don't have "a compiled list" I think I was being a bit tongue in cheek, but clearly, my sense of humour is seldom understood, even less so when Rudy's in the thread.

So, a list is a good idea. To that end I have utility that dumps the activex properties and dxf codes in one swoop, ala vlax-dump-object and (enget ename appidlist) <not that it's a big deal>. I'll clean it up and post it later tonight. One of the nice things is that it will accept an object, an ename or a handle as an argument; there's a wrappered command line version too.

It's one of the first apps I wrote when making the transistion from vanilla to visual lisp; I found it helped me a lot. While you (Mr. Madsen) will have no use for it, others, lurking and otherwise, may find it useful. It prints the data out like this:
Code: [Select]
; IAcadBlocks: The collection of all blocks in the drawing
; Property values:
;   Application (RO) = #<VLA-OBJECT IAcadApplication 00af9594>
;   Count (RO) = 3
;   Document (RO) = #<VLA-OBJECT IAcadDocument 01038600>
;   Handle (RO) = "1"
;   HasExtensionDictionary (RO) = 0
;   ObjectID (RO) = 2130005000
;   ObjectName (RO) = "AcDbBlockTable"
;   OwnerID (RO) = 0
; Methods supported:
;   Add (2)
;   Delete ()
;   GetExtensionDictionary ()
;   GetXData (3)
;   Item (1)
;   SetXData (2)
; DXF Group Codes:
;   (-1 . <Entity name: 7ef54c08>)
;   (0 . "TABLE")
;   (2 . "BLOCK_RECORD")
;   (330 . <Entity name: 0>)
;   (5 . "1")
;   (100 . "AcDbSymbolTable")
;   (70 . 1)
I had passed a handle value of "1" to display the preceeding. Here I'm selecting a viewport with frozen layers so you can see how it formats the extended entity data:
Code: [Select]
; IAcadPViewport: IAcadPViewport Interface
; Property values:
;   Application (RO) = #<VLA-OBJECT IAcadApplication 00af9594>
;   ArcSmoothness = 1000
;   Center = (4.94046 4.03018 0.0)
;   Clipped (RO) = 0
;   CustomScale = 0.405282
;   Direction = (0.0 0.0 1.0)
;   DisplayLocked = 0
;   Document (RO) = #<VLA-OBJECT IAcadDocument 01038600>
;   GridOn = 0
;   Handle (RO) = "91"
;   HasExtensionDictionary (RO) = 0
;   Height = 4.54177
;   Hyperlinks (RO) = #<VLA-OBJECT IAcadHyperlinks 03098cb4>
;   Layer = "0"
;   LensLength = 50.0
;   Linetype = "ByLayer"
;   LinetypeScale = 1.0
;   Lineweight = -1
;   ObjectID (RO) = 2130005704
;   ObjectName (RO) = "AcDbViewport"
;   OwnerID (RO) = 2130005312
;   PlotStyleName = "ByLayer"
;   ShadePlot = 0
;   SnapBasePoint = (0.0 0.0)
;   SnapOn = 0
;   SnapRotationAngle = 0.0
;   StandardScale = 1
;   Target = (0.0 0.0 0.0)
;   TrueColor = #<VLA-OBJECT IAcadAcCmColor 03099090>
;   TwistAngle = 0.0
;   UCSIconAtOrigin = -1
;   UCSIconOn = -1
;   UCSPerViewport = -1
;   ViewportOn = -1
;   Visible = -1
;   Width = 4.95263
; Methods supported:
;   ArrayPolar (3)
;   ArrayRectangular (6)
;   Copy ()
;   Delete ()
;   Display (1)
;   GetBoundingBox (2)
;   GetExtensionDictionary ()
;   GetGridSpacing (2)
;   GetSnapSpacing (2)
;   GetXData (3)
;   Highlight (1)
;   IntersectWith (2)
;   Mirror (2)
;   Mirror3D (3)
;   Move (2)
;   Rotate (2)
;   Rotate3D (3)
;   ScaleEntity (2)
;   SetGridSpacing (2)
;   SetSnapSpacing (2)
;   SetXData (2)
;   TransformBy (1)
;   Update ()
; DXF Group Codes:
;   (-1 . <Entity name: 7ef54ec8>)
;   (0 . "VIEWPORT")
;   (330 . <Entity name: 7ef54d40>)
;   (5 . "91")
;   (100 . "AcDbEntity")
;   (67 . 1)
;   (410 . "Layout1")
;   (8 . "0")
;   (100 . "AcDbViewport")
;   (10 4.94046 4.03018 0.0)
;   (40 . 4.95263)
;   (41 . 4.54177)
;   (68 . 2)
;   (69 . 2)
;   (12 6.0 4.5 0.0)
;   (13 0.0 0.0 0.0)
;   (14 0.5 0.5 0.0)
;   (15 0.5 0.5 0.0)
;   (16 0.0 0.0 1.0)
;   (17 0.0 0.0 0.0)
;   (42 . 50.0)
;   (43 . 0.0)
;   (44 . 0.0)
;   (45 . 11.2064)
;   (50 . 0.0)
;   (51 . 0.0)
;   (72 . 1000)
;   (331 . <Entity name: 7ef54e88>)
;   (331 . <Entity name: 7ef54e90>)
;   (331 . <Entity name: 7ef54e98>)
;   (90 . 32864)
;   (281 . 0)
;   (71 . 1)
;   (74 . 0)
;   (110 0.0 0.0 0.0)
;   (111 1.0 0.0 0.0)
;   (112 0.0 1.0 0.0)
;   (79 . 0)
;   (146 . 0.0)
;   (170 . 0)
;   (-3
;      (
;         "ACAD"
;         (1000 . "MVIEW")
;         (1002 . "{")
;         (1070 . 16)
;         (1010 0.0 0.0 0.0)
;         (1010 0.0 0.0 1.0)
;         (1040 . 0.0)
;         (1040 . 11.2064)
;         (1040 . 6.0)
;         (1040 . 4.5)
;         (1040 . 50.0)
;         (1040 . 0.0)
;         (1040 . 0.0)
;         (1070 . 0)
;         (1070 . 1000)
;         (1070 . 1)
;         (1070 . 3)
;         (1070 . 0)
;         (1070 . 0)
;         (1070 . 0)
;         (1070 . 0)
;         (1040 . 0.0)
;         (1040 . 0.0)
;         (1040 . 0.0)
;         (1040 . 0.5)
;         (1040 . 0.5)
;         (1040 . 0.5)
;         (1040 . 0.5)
;         (1070 . 0)
;         (1002 . "{")
;         (1003 . "MyLayer")
;         (1003 . "YourLayer")
;         (1003 . "OurLayer")
;         (1002 . "}")
;         (1002 . "}")
;      )
;   )
Sorry for chewing bandwidth with that one.

Oh, look at that, time for supper, catch ya later,

Michael.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
The future of DXF codes?
« Reply #8 on: May 25, 2004, 11:36:36 PM »
Quote from: Michael Puckett
I'll clean it up and post it later tonight.
I have just under 300 lines of code to post, what's the preference, post in line or attach a text file (is the latter possible?).
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
The future of DXF codes?
« Reply #9 on: May 26, 2004, 12:13:37 AM »
Michael :

Since you have a folder here   http://www.theswamp.org/lilly.pond/

perhaps just download the lisp < files > as a zip to that folder.

Then reference the zip in your post.

I haven't tried, so this is a guess [ To assume, presume, or assert (a fact) without sufficient information ]

regards.Kerry
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
The future of DXF codes?
« Reply #10 on: May 26, 2004, 02:02:31 AM »
Quote from: Kerry Brown
Perhaps just download the lisp < files > as a zip to that folder.
Thank you Kerry, I didn't know if the pond was "disclosable" or not; thanks for clarifying.

Here it is zipped.

Perhaps someone will find it helpful.  Problems? I'll fix tomorrow night (providing you share details).

ZZZzzz
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
The future of DXF codes?
« Reply #11 on: May 26, 2004, 03:20:51 AM »
Nice ..  I like the combined output.

I like the ninfo option too. .. handy.

how about incorporating the 320, 330, 340, 350, 360 sub data ??

 ... in the style of :
Code: [Select]

(defun c:dxfListChildren (/ eko)
;;; kwb @ VbExpresso
  ; Global variables: (*LENT* *LENT320* *LENT330* *LENT340* *LENT350* *LENT360*)
  (setq eko (getvar "cmdecho"))
  (setvar "cmdecho" 0)

  (setq *lent* (entget (car (entsel "\nSelect entity to display its DXF value data: ")) '("*")))
  (textscr)
  (list *lent*)
  (foreach n *lent* (print n))
  (if (and (assoc 320 *lent*) (setq *lent320* (entget (cdr (assoc 320 *lent*)))))
    (progn (prompt "\n\n Dump DXF 320 listing ... ")
           (list *lent320*)
           (foreach n *lent320* (print n))
    )
  )
  (if (and (assoc 330 *lent*) (setq *lent330* (entget (cdr (assoc 330 *lent*)))))
    (progn (prompt "\n\n Dump DXF 330 listing ... ")
           (list *lent330*)
           (foreach n *lent330* (print n))
    )
  )
  (if (and (assoc 340 *lent*) (setq *lent340* (entget (cdr (assoc 340 *lent*)))))
    (progn (prompt "\n\n Dump DXF 340 listing ... ")
           (list *lent340*)
           (foreach n *lent340* (print n))
    )
  )
  (if (and (assoc 350 *lent*) (setq *lent350* (entget (cdr (assoc 350 *lent*)))))
    (progn (prompt "\n\n Dump DXF 350 listing ... ")
           (list *lent350*)
           (foreach n *lent350* (print n))
    )
  )  
  (if (and (assoc 360 *lent*) (setq *lent360* (entget (cdr (assoc 360 *lent*)))))
    (progn (prompt "\n\n Dump DXF 360 listing ... ")
           (list *lent360*)
           (foreach n *lent360* (print n))
    )
  )
  (setvar "cmdecho" eko)
  (princ)
)

This is a little primative, but you will get the idea.
Ideally it could handle repeats and deep nesting properly .. but that was not a squeaky wheel issue at the time .. :)
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
The future of DXF codes?
« Reply #12 on: May 26, 2004, 03:27:34 AM »
Quote
I didn't know if the pond was "disclosable" or not;


oh ...

the link seems to be listed liberally throughout the site ..

so I hope so ...
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

Mark

  • Custom Title
  • Seagull
  • Posts: 28753
The future of DXF codes?
« Reply #13 on: May 26, 2004, 07:49:50 AM »
Quote from: Kerry Brown
the link seems to be listed liberally throughout the site .. so I hope so ...

It is.  :D
TheSwamp.org  (serving the CAD community since 2003)

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
The future of DXF codes?
« Reply #14 on: May 26, 2004, 08:23:05 AM »
Quote from: Kerry Brown
Nice ..  I like the combined output.

I like the ninfo option too. .. handy.
Thank you Kerry; nice to have feedback already.
Quote from: Kerry Brown
how about incorporating the 320, 330, 340, 350, 360 sub data ??
That could be implemented very easy by recursion, but with the amount of data this thing spews out you would frequently breach the limits of the text screen, or have to scroll endlessly to find the parent dump; that gets old REAL fast :(

I have another utility that is far more ambitious than this that might be more suitable for what you're after, it's a melding of vb and vl that lets you walk around the object model real time (in traditional explorer view, ala treeview & listview), but it's not ready for public consumption. Perhaps you'll find it useful, or interesting, or neither. When it's ready TheSwamp will get first looks.

Off to work! Have a great day all,

Michael.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst