Author Topic: Acad3DPolyline and Add3DPoly()  (Read 3376 times)

0 Members and 1 Guest are viewing this topic.

StefanDidak

  • Guest
Acad3DPolyline and Add3DPoly()
« on: July 27, 2007, 07:31:33 PM »
Hi folks,

I had to jump into some C# code for a Civil 3D add-on and have managed to wade through the API docs only to discover that I also had to wade through the managed API of the ARX docs, etc. So far setting up the framework has been fairly painless but I keep coming back to one bit of code that still has me mystified.

In the original code that I'm overhauling a bunch of 3D polylines are created via the following method:

Code: [Select]
modelSpace = Application.AcadApplication.ActiveDocument.ModelSpace;
Acad3DPolyline poly = modelSpace.Add3DPoly(pointArray);

where pointArray is an array of doubles. This is working fine but the jumble of API docs doesn't appear to explain anything about it. In fact, all the docs and training material mostly refers to the use of Polyline3d and how to add it to the drawing using the WorkingDatabase and TransactionManager.

The code involved to perform the polyline creation and addition via DB transactions is certainly a lot more than the simpler Add3DPoly() call that I am seeing in the code that I'm working through. Does anyone have an idea on which of the methods would be preferable, more reliable, or just better? Is there any good reason to avoid using the Add3DPoly() solution?

Jeff_M

  • King Gator
  • Posts: 4099
  • C3D user & customizer
Re: Acad3DPolyline and Add3DPoly()
« Reply #1 on: July 27, 2007, 08:09:43 PM »
Hi Stefan, welcome to theSwamp!

I'm sure someone will correct me if I'm wrong, but it appears that you are using the ActiveX method which does all of the work for you. So if you want to be using the .NET managed libraries, which are supposed to be faster to execute, you'd need to go back to the Transactions.

But, I'm still learning this stuff, too.

StefanDidak

  • Guest
Re: Acad3DPolyline and Add3DPoly()
« Reply #2 on: July 27, 2007, 08:18:56 PM »
Thanks, Jeff.

I stumbled upon this forum after searching around for things I couldn't find on ADN. Which is definitely a thumbs up for the forum!  :-)

Because C3D isn't really part of my realm of experience (and I've only started this since a week ago) I've been looking to fast-track some development while avoiding the bulk of the API where possible. I somehow expected a cleaner .NET API but I'm starting to see there's a ton of baggage still being lugged around via COM Interop. I'll try some performance tests on large numbers of polylines to see what the difference is between the AX call and the .NET transactions.

Jeff_M

  • King Gator
  • Posts: 4099
  • C3D user & customizer
Re: Acad3DPolyline and Add3DPoly()
« Reply #3 on: July 27, 2007, 09:31:52 PM »
Well, if there's anything we can try to help with just holler. There's quite a few pretty darn good .NET coders around here with one of them, and myself, that have used the C3D API as well.

LE

  • Guest
Re: Acad3DPolyline and Add3DPoly()
« Reply #4 on: July 27, 2007, 09:38:31 PM »
Welcome Stefan.

Interesting office you have (in case that is a real one :) )


ADN stand for:

Ask but we Don't kNow the answer but keep trying

StefanDidak

  • Guest
Re: Acad3DPolyline and Add3DPoly()
« Reply #5 on: July 28, 2007, 12:33:47 PM »
Oh, the home office is definitely real. Two are currently covered in C3D API docs, two others have C3D/VS2005 and on one of the side screens I'm writing this right now.

How about Absolutely Not Detailed? :-)

sinc

  • Guest
Re: Acad3DPolyline and Add3DPoly()
« Reply #6 on: August 09, 2007, 05:37:08 PM »
Or using some common American vernacular: 

Absolutely Detailed - NOT!

StefanDidak

  • Guest
Re: Acad3DPolyline and Add3DPoly()
« Reply #7 on: August 09, 2007, 06:26:15 PM »
Today it turned out to be mostly a matter of Absolutely Daft Notation... when I ran into an official doc sample referring to an IAeccBaseBaseline that I couldn't resolve or find, only to discover that it's really called an IAeccOffsetBaseline instead. No wonder the .NET DLL's aren't obfuscated... no need to do that, even with the docs it can get quite incomprehensible. :-)