Topic: Suggestions Understanding the API

[Jeff H]

Basiclly I have book on the API, and I learn some things from it but what good is it with 4 lines of explanation then 10 pages of code that with a couple of lines changed each page.
I use fourms and the online devleoper reference
Mainly I use the arxmgd and MgdDbg and other snoop databases

Any suggestions on other resources on understanding the API
Are the ObjectARX guides a good place I am not worried about code language
Well that was probably a stupid question since that the classes that are being wrapped.
Any suggestions would be greatly appreciated

[Kerry]

morning Jeff,

I assume you're using this :
http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%20.NET%20Developer's%20Guide/index.html

I've found Reflector helpfull ... but it's NOT documentation API help
http://www.red-gate.com/products/reflector/index.htm

The AutoCAD .NET API Documentation is abysmal. Perhaps if everyone sent an email to Kean each week AutoDESK would do something about it .. or perhaps not  

[Jeff H]

I recently joined the ADN hoping there was good documentation but if you can access Au online and autodesk website you get the same thing, the support is pretty good if you have the standard like I do you usually figure it out before you recieve an email.

[LE3]

I took the ObjectARX route.

[sinc]

If you're using ObjectARX, how has it affected you, now is that Autodesk has started adding new API functionality only to the .NET API?  Or has it created any issues for you at all yet?

I believe you can access all of this .NET stuff from C++, but I've been working pretty much exclusively in C# for the last four years, and haven't even looked at what's involved.  Is it relatively simple to do?

[Jeff H]

I thought all the .NET were wrappers around the c++

[sinc]

Looking at the ObjectARX dev kit, it does appear that the .NET API for the core product is basically a wrapper around the ObjectARX...  One part I found funny was when the documentation said that Autocad events were mapped to reactors in ObjectARX, which were then mapped to events in .NET...   

However, it seems to be a different story with the vertical products.  At this point, we don't have DBX access to vertical applications like Civil 3D, and Autodesk has deprecated COM and started releasing all new improvements only in the .NET API.  That means there is a growing set of functionality in the vertical products that can only be accessed via the .NET API.

[LE3]

Yes...

I tried to go the COM route for a plugin for MEP and it was so hard, that even the guys at the adn, recommend to avoid it, and simple to use the C# API side.

[It's Alive!]

Is it relatively simple to do?

To answer your question about native/managed interoperability, it's not hard at all, in fact it's fairly simple once you get your arms around C++/CLI. The only sucky thing is that none of the VS versions have good intellisense support for C++/CLI, so the environment is not user friendly. Getting a copy of VAssistX helps tremendously though.

As LE pointed out some COM stuff is a pain in the butt with C++, this is where it really make sense to add .NET (C# or C++/CLI) to your solution

[LE3]

For my case, they also said to avoid COM for MEP access in the future, since they were going the C# route only.

One of these days, if I can, will try to post my COM code to access MEP....  :ugly:
 

Is it relatively simple to do?

To answer your question about native/managed interoperability, it's not hard at all, in fact it's fairly simple once you get your arms around C++/CLI. The only sucky thing is that none of the VS versions have good intellisense support for C++/CLI, so the environment is not user friendly. Getting a copy of VAssistX helps tremendously though.

As LE pointed out some COM stuff is a pain in the butt with C++, this is where it really make sense to add .NET (C# or C++/CLI) to your solution