What API should I learn?

[guitarchitect7]

To lift the clouds from your eyes, try typing "VBAIDE" at the command line in AutoCad.

The words of wisdom

[Avatart]

The words of wisdom

Personally I prefer typing VLIDE, but that will be consigned to history in the near future.

[dgorsman]

I want to throw out an example real quck if I can. Within lisp I have written a program to create all the necessary layers needed within our projects. By the click of the button they are created with all the correct variables. In general terms, can this be done with VB? Thats where I'm contemplating. Can I do some of these things I have done with lisp but now only with VB?

Anyway, I'll stop typing now.

VB .NET can do much, much more that LISP. For example, with .NET you could maintain the layer settings in an external data file. A user module would provide programmatic access for manipulating layer information in drawings, while an admin module could provide the CAD Manager with the ability to maintain those standards, as well as automatically update electronic standards, web-based documents, and dispatch notification emails to users about what has changed. On the flip side, its easy to get lost in all the details.

Not sure about that last question: "Can I do some of these things I have done with lisp but now only with VB?" If you are asking if LISP has lost any functionality, I'd have to say "no".

[dgorsman]

Personally I prefer typing VLIDE, but that will be consigned to history in the near future.

I don't see it happening for at least 10 years. Its popular enough, and there is so much of it in companies, that unless something just as simple and fast (drag-n-drop icon based programming?) comes along somebody will keep it running.

[Avatart]

I don't see it happening for at least 10 years. Its popular enough, and there is so much of it in companies, that unless something just as simple and fast (drag-n-drop icon based programming?) comes along somebody will keep it running.

Sorry, I wasn't trying to imply that Lisp will be consigned to history, just that I will be moving on to VBA, so I can program for Revit.

Personally I hope that Lisp lives on for ages, cos I spent years learning the little that I know and don't want that going to waste.

[Ed Jobe]

... I'm learning VB with Visual Studio .... From there I would like to explore VB.NET

Unless you're working with a version of VS that's 4-5 years old, you have been using VB.Net all along.

[guitarchitect7]

Unless you're working with a version of VS that's 4-5 years old, you have been using VB.Net all along.

Well what do you know. I just started looking into it this week. I have used the VBA that is within AutoCAD 2008, and then downloaded VS Express as well. This is at least good to know then.

I am beginning to see the upside of VB, but it also seems that there is a need for VLisp to accommendate the VB program. There is much to learn and the tuturiols have been great so far. I think the next step is to see some useful code and try to decifer what it's saying and how to use it.

Thanks for the input and help with things.

[sinc]

I think in my case it is just fear of change that is worrying me, that and the huge task of learning a programming language from scratch. It's taken me about fifteen years to get where I am with Lisp (and, truth be told, that's not very far!), now I've got to do it all over again in .NET or VBA or C++ or whatever....

If that is your primary concern, then I would say learn .NET. In fact, I would generally recommend that anyone interested in customizing Autocad learn .NET.

VBA is dying. Microsoft is not porting it to 64-bit, and for applications like Autocad that want to keep using it in 64-bit, the VBA is executed in a separate 32-bit process, which results in a significant performance loss. So looking forward, VBA is not a good choice. The writing is already on the wall for that one. If you start learning that one now, chances are good that you will need to learn VB.NET in the not-too-distant future. And if you are going to learn VB.NET anyway, there's no good reason to learn VBA first. In some ways, learning VBA can make it harder to learn VB.NET, because you will most-likely learn some "bad habits" from VBA.

Lisp is useful in some ways, but I've grown to think of it as a "macro" language. The nice aspects of it are that it has a relatively small-but-powerful instruction set, and it's been in Autocad for a very long time now. The drawbacks of it are many. The "List" construct is powerful, but not always easy to use, especially compared to the .NET collection classes. The functional programming aspects (mapcar, etc.) are powerful, but do not make for the most-readable or easily-understood algorithms. This "logic puzzle" aspect of Lisp is part of why it is so popular for some - it can be lots of fun solving the "puzzles" - but a language that is easy to read and write is better. The IDE is weak, missing many features, and difficult to use compared to something like Visual Studio Express. Also, the Lisp interface as a whole is something that Autodesk is not paying any attention to. Newer Autocad features, especially in the various vertical products, are either inaccessible or accessible only with great difficulty from Lisp. And there is not much in the way of support classes, so simple tasks can require lots of Lisp coding to implement, while by contrast, the functionality may be included by default in the .NET framework.

C++ is a rather messy programming language. It is the one to use if you need complete access to as much of Autocad as you can get to without working for Autodesk, and it is also the choice when you are doing some large, complex task and speed of execution is of vital importance. But the language itself is difficult to learn, and even harder to master, and you can really get into some messes with it. So unless you absolutely need the speed and power of C++, I recommend avoiding it.

People like to say that .NET is a lot harder than Lisp or VBA, but I don't really think so. There are a few problems right now with .NET. The biggest is that the .NET interface to Autocad is basically nothing but a wrapper around the ObjectARX interface, and it is not a complete wrapper. This can lead to times when the programmer may need to mix .NET and COM, which complicates the code and can create confusion. Another very big problem is that nearly all of Autodesk's developer documentation and examples are written for VBA, so the .NET programmer must "translate". This can be tricky, especially for the beginner. Then there is also the fact that the .NET framework is very large, and intimidating at first. But you only need to learn a very small part of the overall .NET framework in order to start customizing Autocad. The very-large .NET framework is generally an asset, because when you need to do a specific task, you can search for something that might help. Often, there's a class in the .NET framework that does a lot of what you want, and you need to write very little code yourself.

There is another drawback to .NET, again related to the incomplete wrapping of the underlying ObjectARX classes. It is not always possible to do everything using Autocad's managed wrapper, which means you may be forced to link in the Interop libraries and manipulate the COM objects. When you do this, the compiled version of your .NET code will only work with that same version of Autocad. So you may find that you need to compile multiple versions of your .NET application, one for each version of Autocad that you are targeting. This problem did not exist with Lisp and VBA. But hopefully, all your users will all be on the same version of Autocad, anyway, so this shouldn't be a real issue for most.

[sbrusco.104765]

This thread is as close to anything i've found to answer my question. I am, by my employer's dictate but also by my own desire, moving to Visual Studio's dotNET IDE for customizing Autodesk's CAD apps. I am already familiar with and will continue to use VLisp/VBA when the tasks are small(er) because these are quick to throw together and get quick results.

However, we are embarking on quite a sizeable program that will require the incorporation of an SQL database to maintain and share data across users and projects, and the program-creation of custom objects that can be used in the drawings created by the CAD application. So this is my question.

If I'm already resigned to the dotNET framework, what are the pros and cons of VB, C# and C++? How do these compare? I was told VB.NET within AutoCAD will be going away. Is this true? Is it true that C++ is the source language for AutoCAD? If so, does this give C++ an advantage?

Sal

[Ed Jobe]

If I'm already resigned to the dotNET framework, what are the pros and cons of VB, C# and C++? How do these compare?

All the development languages work on the same intermediate language. Therefore the development language is mostly a matter of personal preference. Sometimes one language may have an advantage over another. For example, MS is coming out with a new language, F#. It is a functional language, similar in concept to lisp. However, you can use all of the languages in the same project and easily translate between them. I can get sample code in C# and translate it to VB and vice versa.

I was told VB.NET within AutoCAD will be going away. Is this true?

Not to my knowledge. Perhaps they meant vba? Even that is hard to say.

Is it true that C++ is the source language for AutoCAD? If so, does this give C++ an advantage?

Yes. More control may be needed. However, the NET api is a fairly complete wrapper for the C++ libraries. So in most cases, its not needed.