Autolisp or .net

[FatRobo]

Hi all,

 

I am looking to further my skills in streamlining the day to day running of some of the offices CAD tasks using lisp or something of the like.

 

Someone the other day mentioned to me .net. Now I can appreciate this might be something you can argue until the cows come home but I was looking to get some perspective on which lanuage I should learn. What are the pros and cons of each? Is one phasing out? Is one more power than the other?

 

You advice is much appreciate.

 

Chris.

[Kerry Brown]

Chris,

Lisp may be the better choice for simple customisation and medium sized apps.

The learning curve for .NET is fairly protracted and the lisp knowledge you gain will be a small help when you choose to make the transition.

Lisp is not being phased out, and the nature of the language suits "try it and see" experiments much better than the compiled .Net languages.

 

There is a lot of lisp examples available and help is generally just a polite question away

 

Good fortune in your endevours.

[BIGAL]

Lisps probably outnumber .net about 10million to 1 its been around from day dot with Autocad the move to higher level programming is about people pushing the envelope trying to do more and more. The old common lisp still works everyday, vlisp took over now.

 

.net opens up the world to other stuff internet linking maybe a movie of your blocks and pick which one probably stuff people are dreaming of. It is faster.

 

As a ex civil software sales manager was asked why can't the software design the road well what we use now is trying hard to do it without user input. It was done in vba now .net and much more powerfull.

 

Look at draw a box in lisp v's .net 5 times the code. If its something simple, lisp is the way to go.

[Patriiick]

You have to consider that LISP does not offer easy dialog box design and managing. Things that are very powerful with VBA or VB NET.

[Tyke]

One big advantage of LISP over .NET is the LISP you write today will still run on all future and older versions of AutoCAD, whereas .NET is version specific and what you write for AutoCAD 2011 will not work on 2010 or 2012 (when it comes out). That means a different version of your dll for every version of AutoCAD you are using.

 

I'm not a .NET wizzkid but no doubt someone will come back with loads of advice on late binding and how to get the dll to run on all versions.

 

I use LISP, VBA and .NET, and the LISP routines I wrote way back in the nineties are all still working fine today. (Okay some very minor mods to deal with changes in AutoCAD) The VBA modules have also stood the test of time, but VBA is on the way out, you have to download and install the VBA enabler for each current flavour of AutoCAD that is on the market. If there will be one made available for 2012 no one knows, personally I think there will be one but that it will be the last one. After that it will be LISP or .NET.

[irneb]

You have to consider that LISP does not offer easy dialog box design and managing. Things that are very powerful with VBA or VB NET.

There is an add-on (Open Source) available called OpenDCL which allows for the same type of visual dialog design as you get in Visual Studio (C++, C# or VB.Net). It's simply an ARX which needs to be loaded into ACad, then you have several new lisp functions for opening dialogs (modal or non-modal), adding a tab into Options, creating palettes, and control bar (like a dockable tool window). So even for that it's not a must-have-VS scenario.

 

Where I would say you need DotNet (or even ObjectARX ... which is an even longer learning curve) is when you want to perform things on new object types or create your own object types. Those things which are impossible or extremely difficult to do with only the DXF manipulations of AutoLisp or the ActiveX/COM manipulations of VisualLisp.

 

I use both Lisp and VB.Net, but I'd say I program 99% of the time in Lisp. It's just when I'm bumping my head against a wall that I open VS. And then only to create a function which I can call from the lisp project I'm making. This may be the "wrong" way about it, but it works for me.

[jlarri]

Helo irneb!!

I use visual lisp and for the dialogue controls vb6 activex dll, but I'll like to develop activex dll with visual studio net 2010 and call from visual lisp. I have trayed, but I've problem for registration dll. Can you send me samples with open code of visual studio class library and visual lisp routine? Sorry for my english. Thank you in advance

[irneb]

Helo irneb!!

I use visual lisp and for the dialogue controls vb6 activex dll, but I'll like to develop activex dll with visual studio net 2010 and call from visual lisp. I have trayed, but I've problem for registration dll. Can you send me samples with open code of visual studio class library and visual lisp routine? Sorry for my english. Thank you in advance

Are you simply trying to make a dialog in VS which you can control through ALisp? If so it's not the easiest way to go about it from an ActiveX route. You'd have to make public-callable methods in the DLL through ActiveX connections. And since you load the DLL into ACad what form is it taking (ARX / DotNet)?

 

If your "dll" is strictly a VB6-like ActiveX control - then you'd need to see it as an external program in its entirety. Similar to thinking of it as Excel, though it's apparently possible to use it through the GetInterfaceObject method (I've never used it this way before). Thus it needs to be an executable thing of its own, which then acts as an ActiveX server so VLisp can link to it. This makes it extremely convoluted as you'd need to link back to ACad to get the data or use yet more functions such that VLisp can send it the data from ACad.

 

IMO a much better solution is to just use OpenDCL. You get dialogs at least comparable to VS's dialog designer (especially if you only use the VB6-like ActiveX stuff). Note VS2010 is a long way past VB6 - it's now VB.Net.

 

Or alternatively (and probably even more customizable) is to use VB.Net or C# directly in VS, then use the LispFunction decorator to make new lisp callable functions so you can control / send / recieve info between ALisp and DotNet. See this writeup: http://through-the-interface.typepad.com/through_the_interface/2006/07/breathe_fresh_l.html