ObjectARX, .NET, C++, C#... which one?

[cadproman]

With the removal of VBA coming soon, it looks like I need to learn a real programming language. I have 10 years of old programming done in VBA that will need to be updated. After looking around for more than a week, I'm still confused on what direction to take, and I was wondering if I could get some input from you guys. Should I be concentrating on .NET or ObjectARX? (I don't actually know the difference) Is C++ or C# the way to go? It seems that one difference is that custom entities can be created with C++, but not C#? I made the mistake of taking the easy way out before and learning VBA instead of C++, so with that hindsight, I don't mind taking the time to learn the harder one if it is more powerful. Also, if ObjectARX is the way to go, where can I get the ObjectARX 2007 SDK? I would like to start updating all of my older stuff before we upgrade, and I don't see where the older SDK's can be found. Is this a good idea? It seems that as long as it is in the right language, I can just recompile with the new SDK with small changes to use it in the newer versions of AutoCAD?

TIA for any input. It will be very much appreciated.

Ralph Gaston

[PSharpe]

The .Net assemblies for AutoCAD provide managed wrappers to the ObjectARX COM objects (if my understanding is correct, and i dont mind being corrected here) this takes alot of the memory management concerns away form the programmer as the CLR garbage collector takes care of this for you. You can still reference the old VBA ObjectARX COM classes from .Net if you wish.

Since Autodesk are as you say moving away from VBA and to some extent LISP (I read an article somewhere, sorry cant remember the link that stated new features would only be rolled out in the managed API and not LISP) the .Net environment would appear to be the way to go.

I learned C++ for my degree and it is a very different language to VB to program in. VB is very forgiving of implicit conversion of variable and objects etc where as C++ requires everything to be explicit (Think Option Strict with bells on) Just one simple example of a difference. VB.net and C#.Net both get compiled to MSIL code so there is little performance difference between the 2. If your comfortable with VB i would suggest going down the VB.Net route.

Having said that i do have to write in VB these days as its what my boss understands, but i do miss C++

[Anonymous]

---

@PSharpe wrote:

The .Net assemblies for AutoCAD provide managed wrappers to the ObjectARX COM objects  

---

The .NET assemblies for AutoCAD provide managed wrappers for native (C++ based) ObjectARX classes.

Managed wrappera for AutoCAD COM objects (and all other COM objects) are generated automatically by the IDE when you reference a COM type library.

[Anonymous]

Here is my own feedback, and I essencially face the same issue as you do, but I have a bit of experience in .Net.  We have an app that took 2 years to build in VBA / VB6, and are now facing a long migration to .Net because (a) we don't know how long Autodesk will be rolling out VBA enablers for future versions of AutoCAD (but this is a good solution if your VBA app is not too complex - in our case, we run into a memory problem because of memory leaks in our VB app.) and (b) because we will be migrating to 64 bit OSs nex year and VBA does not seem to react the same way on a 64 bit system than on a 32 bit one (especially had a lot of problems with window focus - it may have something to do with the fact that it is Out-Of-Process, but lets not get into that...).

So for your question, the first thing you need to realize is that the.Net framework is the .Net framework, no matter whitch language you use.  Witch is nice, because this means that most C# documentation (or information on forums and such), will also apply to VB, and vice-versa.  To what I ave read, C++ is to be avoided, unless you are doing something that the .Net framework does not do.  Someone else could explain, but I believe that the syntax is a bit too cmplex for what I usually need to do...  but again, .Net is .Net, no matter what language...

Other than that, the difference is the syntax.  I am more confortable in VB syntax (VB6 and VB .Net is very similar), so that would have been my first choice, but most of the developpers that I work with are more confortable in C# so that's where I'll go, and I don't mind at all.  If you did a little bit of Java, the syntax is similar.  Also, (comments from coworkers) is that C# seems to be the new .Net standard.  There is ALOT more code exemples and tutorials made in C#.  Again, it is realy easy to re-write the code to VB, but if you can save that time.....

Anyway, I hope this helps...  It actually helps me to dump all of the my opinions on this subject!

Food for taughts!

[chiefbraincloud]

I had previously worked in VB4,5,6 (not with AutoCAD), and LSP, VBA with AutoCAD, before switching to VB.NET in about 2007.  I would recommend sticking with VB, at least until you complete your initial conversion from VBA into .NET.

It is true that generally speaking there are more examples in C# than VB, but there are also at least a couple of Translators on the web that do a good job, so you can translate the C# examples into VB.  If you are anything like me, then you will start to pick up the C# syntax in the process of doing this.

If you take things one step at a time, a lot of your VBA code won't need much work to put into .NET using the COM API.

Then after you have working VB.NET COM code, you can begin to dive into the Managed API's, and if you want to switch to C#, the aforementioned translators can help take the pain out of switching your VB.NET code to C#.

Also, C# and VB code can not appear in the same assembly, but you can have a VB assembly that references a C# assembly and vice-versa, so it doesn't have to be an all or nothing proposition.

[cadproman]

Thanks to all of you for the responses. If I understand correctly, as long as I am programming in .NET then C++, C#, and VB.NET all have the same capabilities? This was my primary concern because I found that in VBA I did not have access to a couple of important things, such as accessing the Xdata in an object that had been erased, and also no access to a command cancelled event, which apparently are doable in .NET. I still can't seem to find a comparison of the features of C++ to those of C#, but I guess outside of the base items that have nothing to do with the AutoCAD API, they must have equivalent capabilities. If this is not the case, please let me know.

Thanks also for pointing out the existence of code translators. I believe I saw the use of one today on a DevTV webcast. That should really help out when getting stuck.

rg

[Anonymous]

---

@cadproman wrote:

Thanks to all of you for the responses. If I understand correctly, as long as I am programming in .NET then C++, C#, and VB.NET all have the same capabilities? 

---

No, they don't.

C++ can be used to write mixed-mode (managed/unmanaged) code that

can use both the managed API, and the native C++ ObjectARX API.

[Anonymous]

That is true!

And we must keep in mind that all of these languages have their reasons for being here.  This is my breakdown : VB for ease of programming, C++ for extreme power and performance, C# is rght between the 2....  F# will be great for very complex math processing....  and I don't know most of the languages  (http://en.wikipedia.org/wiki/List_of_CLI_languages)...  But in most cases (except for the ObjectARX thing), what you can do in one language, you can do in another.  Note that I don't realy understand the managed / unmanaged code thing...  so I'll let someone else explain...

[PSharpe]

The easiest and most obvious difference between managed and unmanage is that in the managed environment the memory management is taken care of by the CLR Garbage collector. in Unmanaged code the programmer is responsible for the construction, deconstruction and memory management of the code they write.

In C++ it is easy to create memory leaks if you dont code properly, and from experience they can be a real pain to hunt down in larger apps.

While this does mean more work for the programmer is does as others have stated mean more power, control and flexibility, for better or worse will depend on the one doing the programming.

[dgorsman]

C++ is balls-to-the-wall, full-on application programming.  It requires an in depth knowledge of programming concepts, and AutoCAD as well if you are building on top of it.  You can spend years learning all the C++ ins and outs without even touching AutoCAD.  It requires an obsessive-compulsive level of attention to avoid minor mistakes causing major problems like memory leaks.  The upside is that you can make applications that not only sing and dance, but get you a donut and answer the phone as well.

C# hides a lot of the fine details that don't impact most of the off-the-cuff customization while retaining that nice C syntax.  You can still get into trouble but its a lot easier to get started on it.  VB is much more the equivalent than C++, and is probably a better starting point than C# if you have more of a BASIC background.

[Anonymous]

---

@dgorsman wrote:

It requires an obsessive-compulsive level of attention to avoid minor mistakes causing major problems like memory leaks. 

---

No, not really.

Most C++ programming these days relies heavily on the use of things

like smart pointers, automatic variables and classes that use destructor

semantics to automate deallocation/freeing of allocated resources,

thereby eliminating the need for that to be done manually or for the

programmr to have to remember to do it, and effecitively make C++ a

language usable only by someone with OCD.

Additionally, none of those same aspects of native C++ programming

apply to managed C++/CLI.

And regardless of what managed language one uses, AutoCAD's

managed API and its special requirements relating to classes that

implement IDisposable make it a lot like ye olde native C/C++, in that

it (to an unreasoanble extent) requires the programmer to have to

remember to do things they should not have to think about, such as

having to deterministically dispose certain objects, where failing to

do so often leads to a fatal error.

[CADbloke]

chiefbraincloud: "C# and VB code can not appear in the same assembly,"

...actually, they can. You can merge Visual Studio projects into one assembly.

This is my favourite method: http://www.hanselman.com/blog/MixingLanguagesInASingleAssemblyInVisualStudioSeamlesslyWithILMergeAnd...

I found via http://stackoverflow.com/questions/1878807/visual-studio-2008-creating-single-dll-from-solution-with...

... or you can simply reference another project that is in another language. I prefer using the project as a reference, rather than the compliled assembly, for reasons discussed here: http://stackoverflow.com/questions/2029084/vs-net-project-refs-vs-assembly-refs. There is another good discussion on that here: http://stackoverflow.com/questions/1700568/managing-net-assembly-dependencies-by-dll-reference-rathe...

I probably wouldn't go out of my way to mix languages in the same assembly but it's a good way to cut - paste code and get started or build a quick-fix, providing you know what the code is doing. You can always refactor / translate it later, bad habits notwithstanding.

[chiefbraincloud]

While I agree that assemblies can be merged, and I already have my own means of doing that, I still submit that my point was valid.  Merging assemblies made from different languages is not the same thing as making a single assembly that contains code files of different languages.

The point I was trying to make to the OP in that statement was that no matter what he decided about learning c# or not, he did not have to convert all of his code at one time, because he could simply reference a C# assembly into a VB assembly or vice-versa.

Whether or not you merge your assemblies into a single assembly for deployment is another discussion, and in a lot of general programming (not autocad related) or, for retail programming for autocad (my work is currently internal use only), merging the assemblies is probably fine, but in my case, I used to merge my 2 assemblies into one, but now I have 4 different assemblies, 3 of which reference the fourth, but access to each of the three primary assemblies is controlled separately.  Let's call Them P1, P2, P3, and S1.(P1, P2, and P3 all reference S1, But none of the P's reference each other.)  Since access is controlled separately, I can't merge all 4 into 1, so the best I could do is merge each of the P's with S1 and have 3 merged assemblies.  However, there is some overlap in who has access to what assemblies, and if I you tried to load two of those three merged assemblies into AutoCAD at the same time, they would not load together because all of the commands in S1 would be duplicated between them.  Therefore, I do not currently merge my assemblies for deployment.

[CADbloke]

Sorry, Mate.

I wasn't having a dig at you, although I can see now from my wording that it could come across that way.I would edit it but the forum anti-usefulness filter has kicked in on that functionality.

I merely wanted to point out that it is possible. Whether it is a good idea or not is a case-by-case, personal decision. The example you provided is as clear a case as any where merging would be a ridiculous idea.

It wasn't mean as any sort of personal attack - That would be a rotten deal given the level of contribution you make to these forums (particularly compared to mine :/) I was just presenting some knowledge I found in my travels.

cheers

Ewen

[chiefbraincloud]

No worries Ewen.

I took no personal affront, I just wanted to clarify my original point.

Perhaps I should have said 'single project' instead of 'single assembly' in my original post.

 Edited: Sorry, I misspelled your name.

Edited Again: I should also mention that, briefly Quoting you, to 'know what the code is doing' is of utmost importance.  You should not, in my opinion, ever include code in your project that you don't understand.  Translated or otherwise.