Is the .NET API the best tool for "dynamic, non-primative" objects? Or use ObjectARX?

Is the .NET API the best tool for "dynamic, non-primative" objects? Or use ObjectARX?

William.Gates-Crease
Explorer Explorer
565 Views
5 Replies
Message 1 of 6

Is the .NET API the best tool for "dynamic, non-primative" objects? Or use ObjectARX?

William.Gates-Crease
Explorer
Explorer

Hi,


I'm in the early stages of designing a plugin/tool that would allow more dynamic creation of plan objects that need to interact with each other in a fluid way. We are trying to determine if the sort of interactivity we need can be accomplished through the .NET API (preferred due to some of us having C# experience) or if we need to use ObjectARX. 

 

I know that sounds really vague, so let's just say we wanted to create a plugin identical to the built-in Vehicle Tracking tool. When you use Vehicle Tracking, it draws objects on the screen that are dynamically linked, and of a special object type "VehicleTrackingPath". You can of course explode these special objects into primatives.

 

But, when I look at the sample code for .NET in AutoCAD, I only ever see interacting with the modelspace environment to be some form of drawing primatives (lines, circles, hatches, etc). I just want to know if the sort of dynamic 'special object' type that Vehicle Tracking is built on can be done with the .NET API, or if we will need to use ObjectARX to accomplish that. No need for example code! Just want to make sure we make the right choice of which API to use before going too far down the rabbit hole.


Thanks!

0 Likes
566 Views
5 Replies
Replies (5)
Message 2 of 6

ActivistInvestor
Mentor
Mentor

It really depends on what you need from the custom objects, behavior-wise. There are some things you can do using Overrules in the .NET API, which were designed specifically for allowing 'primitive' objects (or composite objects represented as insertions of anonymous blocks) to exhibit custom behavior, without delving into native ObjectARX and custom entities.

 

You should also keep in mind that custom entities have baggage (code) that must accompany the drawing if the custom entities are to be functional. Otherwise, they are represented as proxy objects that display graphics but cannot be manipulated in most ways.  That's not to suggest that overrules don't have baggage, but because they don't use custom objects, the primitive entities just don't exhibit custom behavior when the overrule code isn't loaded.

 

 

 

 

Message 3 of 6

William.Gates-Crease
Explorer
Explorer

This is helpful information.

 

What we are trying to build is a less involved version of the Civil3D subassembly + corridor workflow for creating cross-sections and applying them to alignments, all in 2D. With the idea being that you can create a road cross-section as a 'special' object that can sit somewhere in the drawing, then 'apply' that section to a polyline and it will dynamically offset + place blocks accordingly. And making adjustments to the polyline after the fact, or adding or removing elements of the cross-section, would dynamically update without needing to re-create geometry.

 

It sounds like that can be accomplished with Overrules in the .NET API. Thanks!

 

 

0 Likes
Message 4 of 6

daniel_cadext
Advisor
Advisor

ObjectARX is always the way if you can program in C++. Both overrules and custom entities have their pros and cons. But why start with the lesser API when you can do all of the above in ObjectARX?

Python for AutoCAD, Python wrappers for ARX https://github.com/CEXT-Dan/PyRx
0 Likes
Message 5 of 6

ActivistInvestor
Mentor
Mentor

For what you describe, I would favor overrules over custom objects.

 

Sections can be represented as insertions of anonymous blocks that have a link to the object(s) that affect their appearance, and can be updated when those linked objects change. Doing that doesn't require custom objects and using custom objects for something like that would be unwise for a number of reasons.

 

For example, you can't predict the future, including where your drawings might need to go (for example, accessed using a competing CAD product that doesn't support ObjectARX).  Even producing hardcopy can be complicated by custom objects.

 

IOW, Overruled primitive objects can go places that custom objects can't go.

 

The original purpose of custom objects was as much strategic as it was functional. Custom objects can lock you into using AutoCAD or supporting Autodesk products to access your custom object-based data.

0 Likes
Message 6 of 6

daniel_cadext
Advisor
Advisor

Some things I would think about

1, How do you want your object(s) to be represented when your module is not loaded.  With custom objects, you get an explodable proxy graphic, with overrules, you get the original primitive.

 

2, How do you want your object(s) to behave? Is “VehicleTrackingPath” an object that will mostly behave like a 3d polyline? Trim, extend, split?

If there’s nothing special, then an overrule may be the correct approach. If you need custom behaviors…

 

3, How do you want your object(s) to behave with respect to other APIs. If this object is something for internal use, then there’s less to worry about. However, if it’s intended to be something public, and you are using overrules, you have to assume that your object will get caught up in someone’s selection set filter, whether its someone’s lisp, or quick select. How is your object going to behave if some lisp changes a linetype, or explodes all entities in the drawing that are of your base type?

 

4, Another API question, do you need to expose your object to an API? Lisp, entget, entmod? ActiveX?

 

5, Properties, how do you want your object(s) to behave in the properties palette? This not trivial in either scenario, but it’s definitely something you will want to consider from a user perspective

 

6, data extraction, how is your object(s) going to behave, can you filter it?

 

7, if this is a commercial endeavor? what are your competitors using? Vehicle Tracking looks pretty complicated, I don’t think any are using overrules, but I could be wrong

 

# being locked in to Autodesk products

-Could be an issue, most clones support custom objects, also, it’s not hard port objects to Teigha, but it is more work. Overrule behavior on other platforms also requires work, for example, Teigha derived platforms call WolrdDraw/ViewportDraw multithreaded, whereas AutoCAD does not. Not good or bad, just something to consider.

- Platform if there’s a chance you want your objects to be visible, or come alive on other platforms Mac/linux?

 

Investor has more experience than me, he was already godmode when I was a newb,  probably better to put more weight on his points.

Python for AutoCAD, Python wrappers for ARX https://github.com/CEXT-Dan/PyRx