Topic: ARX vs .NET

[WILL HATCH]

I've been wondering lately... Is there any benefit to going the ARX route at this point?  .NET has been easy to learn and get moving, but at the same time there are many options that aren't available though the managed API.  I find myself misusing elements of the managed API because I haven't been forced to fully understand what's really happening behind it (for example, I read the my first plugin on overrules and could see right away that there was SOOO much that wasn't being explained or understood that I didn't even compile that code for use) because everything crashes nicely in .NET
Can anybody comment?

[TheMaster]

I've been wondering lately... Is there any benefit to going the ARX route at this point?  .NET has been easy to learn and get moving, but at the same time there are many options that aren't available though the managed API.  I find myself misusing elements of the managed API because I haven't been forced to fully understand what's really happening behind it (for example, I read the my first plugin on overrules and could see right away that there was SOOO much that wasn't being explained or understood that I didn't even compile that code for use) because everything crashes nicely in .NET
Can anybody comment?

I use both. About 20% of the AutoCAD code I've written that is in use today, is written in C++ (both native C++/ObjectARX, and C++/CLI for interoperating with managed code)..

Native ObjectARX requires C++ skills, and is more tedious than managed code. Productivity is not not as great. The advantages are performance, and finer granularity in the API.

Perhaps you can cite some examples of the 'many options that aren't available though the managed API', as quite a bit of the native API is exposed to managed code, but in some cases it's not a 1:1 mapping, and the managed equivalent of native APIs may not be obvious.

[WILL HATCH]

Okay, 'many' is a bit exaggerated.. But the hurdle I've encountered that's driving this consideration is drawing audit.  I know I've come across a couple other elements of the API that were only available in ARX but cant think of them at this moment (maybe after I'm finished my coffee  )
Another element driving this, is as I mentioned before my programming background is primarily embedded systems assembly.  I'm used to being very intimate with all the details of an operation and .NET is so far abstracted that it feels a bit like running through the forest in the dark.  I know that working in the PC world I'll never get to pushing bits around registers like I used to but ARX would at least be a way to get my hands deeper into the real process.

I did enough c++ in university to get myself started, however I'm a little concerned that the ARX community may not be as strong as the .NET group is for support.

[TheMaster]

Okay, 'many' is a bit exaggerated.. But the hurdle I've encountered that's driving this consideration is drawing audit.  I know I've come across a couple other elements of the API that were only available in ARX but cant think of them at this moment (maybe after I'm finished my coffee  )
Another element driving this, is as I mentioned before my programming background is primarily embedded systems assembly.  I'm used to being very intimate with all the details of an operation and .NET is so far abstracted that it feels a bit like running through the forest in the dark.  I know that working in the PC world I'll never get to pushing bits around registers like I used to but ARX would at least be a way to get my hands deeper into the real process.

I did enough c++ in university to get myself started, however I'm a little concerned that the ARX community may not be as strong as the .NET group is for support.

If I'm not mistaken, the audit functionality you might see in the native API is not functional. Or at least, I seem to recall that being reported somewhere, but can't remember exactly.

IMO, automate auditing is non-trivial, because it inevitably requires human intervention. Of course, batch auditing with reporting would be useful, and there may be ways of doing it, but I've never explored that area.

[WILL HATCH]

Thanks TT, I didn't want to spend much time going down that road if it didn't have much benefit.

I was under the impression that all the standard commands are executed using the unmanaged API and if there was something I needed to do that couldn't happen in .NET that ARX would do it.

Cheers

[TheMaster]

Thanks TT, I didn't want to spend much time going down that road if it didn't have much benefit.

I was under the impression that all the standard commands are executed using the unmanaged API and if there was something I needed to do that couldn't happen in .NET that ARX would do it.

Cheers

Quite a few out-of-the-box commands are written in managed code. The Layer Properties dialog is entirely managed code, along with the Calculator UI. There's also quite a few commands that are entirely or partially written in managed code.

It doesn't need to be a choice between one or the other. Both can be used.

[It's Alive!]

Thanks TT, I didn't want to spend much time going down that road if it didn't have much benefit.

I was under the impression that all the standard commands are executed using the unmanaged API and if there was something I needed to do that couldn't happen in .NET that ARX would do it.

Cheers

Quite a few out-of-the-box commands are written in managed code. The Layer Properties dialog is entirely managed code, along with the Calculator UI. There's also quite a few commands that are entirely or partially written in managed code.

It doesn't need to be a choice between one or the other. Both can be used.

guess they had to rewrite these for Mac 

[WILL HATCH]

Thanks, your insight is appreciated!

[CADbloke]

guess they had to rewrite these for Mac 

Not necessarily ... http://www.mono-project.com/MonoMac