.NET or VBA

[Anonymous]

Hello,

I am making a comeback into AutoCAD programming after a long, long break. I
now need to develop an application (fairly big) that needs to run under
AutoCAD 2004, 2005 and 2006.

My question is - whether I should use VBA or VB.NET ?

What are the pros and cons of using either?

I read from some posts that .NET is better but the AutoCAD .NET API is
harder to learn. Is this true? What would be the best way to get started?

Regards
Rakesh

[Anonymous]

If you need to run on 2004, then .NET isn't going to
be an option.

.NET first appeared in 2005, but the API wasn't complete
and has some problems. In 2006, it is closer to complete,
but not there yet, and has fewer problems.

Your options are essentially LISP or VBA/ActiveX, or
ObjectARX.


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Rakesh Rao" wrote in message news:5104608@discussion.autodesk.com...
Hello,

I am making a comeback into AutoCAD programming after a long, long break. I
now need to develop an application (fairly big) that needs to run under
AutoCAD 2004, 2005 and 2006.

My question is - whether I should use VBA or VB.NET ?

What are the pros and cons of using either?

I read from some posts that .NET is better but the AutoCAD .NET API is
harder to learn. Is this true? What would be the best way to get started?

Regards
Rakesh

[Anonymous]

Hello,

I am researching info on a task I have. I need to tie together some fields in an excel spreadsheet(stand alone) to dimensions in a acad template file(MDT for parametric's).
Basically, two cells in excel that define the height and width of a rectangle that are linked to two dimensions in a 2D drawing in mdt that will update when excel is updated.

[Anonymous]

Hi,

Nearly everything you need can be found in the sample DVB files supplied
with AutoCAD.
Look in the Sample directory for "ExcelLink.dvb"


--

Laurie Comerford
CADApps
www.cadapps.com.au
wrote in message news:5134053@discussion.autodesk.com...
Hello,

I am researching info on a task I have. I need to tie together some fields
in an excel spreadsheet(stand alone) to dimensions in a acad template
file(MDT for parametric's).
Basically, two cells in excel that define the height and width of a
rectangle that are linked to two dimensions in a 2D drawing in mdt that will
update when excel is updated.

[jbooth]

Just FYI, the .NET framework can easily access Autocad or Excel through COM interop, meaning you could write code in C# or VB.NET that can do whatever you could do with VBA. You can do this in versions of AutoCad as old as 2000 (r15?).

It's a bit more involved though, as you will be limited to a standalone exe or a dll. The advantage however is that you have access to all the .NET libraries and features, including reflection, serialization, System.IO, XML, etc...

[Anonymous]

Hi Jason,

No one is denying this capability, but is it relevant to a question where
the user wants to carry out a very simple task (linking Excel and reacting
to changes in Excel with changes in the drawing or visa versa) which does
not need all this arcane functionality?

More probably he also does not wish to purchase .NET to do this task.

--

Laurie Comerford
CADApps
www.cadapps.com.au

wrote in message news:5135130@discussion.autodesk.com...
Just FYI, the .NET framework can easily access Autocad or Excel through COM
interop, meaning you could write code in C# or VB.NET that can do whatever
you could do with VBA. You can do this in versions of AutoCad as old as 2000
(r15?).

It's a bit more involved though, as you will be limited to a standalone exe
or a dll. The advantage however is that you have access to all the .NET
libraries and features, including reflection, serialization, System.IO, XML,
etc...

[Anonymous]

You don't have to *purchase* .NET, it's free.
If you mean VS2005, let me tell you that the Express and Standard editions
are, considering the bang for ye olde buck, almost free.
As to the 'arcane' functionality' : working with COM in .NET has never been
simpler. It's a breeze.

Hope this helps,
Nemorarius

"Laurie Comerford" wrote in message
news:5135137@discussion.autodesk.com...
Hi Jason,

No one is denying this capability, but is it relevant to a question where
the user wants to carry out a very simple task (linking Excel and reacting
to changes in Excel with changes in the drawing or visa versa) which does
not need all this arcane functionality?

More probably he also does not wish to purchase .NET to do this task.

--

Laurie Comerford
CADApps
www.cadapps.com.au

wrote in message news:5135130@discussion.autodesk.com...
Just FYI, the .NET framework can easily access Autocad or Excel through COM
interop, meaning you could write code in C# or VB.NET that can do whatever
you could do with VBA. You can do this in versions of AutoCad as old as 2000
(r15?).

It's a bit more involved though, as you will be limited to a standalone exe
or a dll. The advantage however is that you have access to all the .NET
libraries and features, including reflection, serialization, System.IO, XML,
etc...

[Anonymous]

The 'FREE' Express versions can't be used to debug
DLLs so they're not really good for AutoCAD based
development.

Regardless of that, the fact that one must pay for
better tools, isn't a legitmate reason to not use
them. If you consider how much better and faster
they let you work, the cost is easily justified.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com

"Nemorarius" wrote in message news:5135889@discussion.autodesk.com...
You don't have to *purchase* .NET, it's free.
If you mean VS2005, let me tell you that the Express and Standard editions
are, considering the bang for ye olde buck, almost free.
As to the 'arcane' functionality' : working with COM in .NET has never been
simpler. It's a breeze.

Hope this helps,
Nemorarius

"Laurie Comerford" wrote in message
news:5135137@discussion.autodesk.com...
Hi Jason,

No one is denying this capability, but is it relevant to a question where
the user wants to carry out a very simple task (linking Excel and reacting
to changes in Excel with changes in the drawing or visa versa) which does
not need all this arcane functionality?

More probably he also does not wish to purchase .NET to do this task.

--

Laurie Comerford
CADApps
www.cadapps.com.au

wrote in message news:5135130@discussion.autodesk.com...
Just FYI, the .NET framework can easily access Autocad or Excel through COM
interop, meaning you could write code in C# or VB.NET that can do whatever
you could do with VBA. You can do this in versions of AutoCad as old as 2000
(r15?).

It's a bit more involved though, as you will be limited to a standalone exe
or a dll. The advantage however is that you have access to all the .NET
libraries and features, including reflection, serialization, System.IO, XML,
etc...

[Anonymous]

Did anyone actually answer your question ?
I have also asked this question on this forum and gotten similar replies. Here is what I think:

.NET is more powerful, versatile and can give you better performance.

but

You have to compile and then install the resulting code on all of your CAD stations. This may be simple if you have a domain with Active directory, but if you need to go to each station to do this it may not be worth it.

Most customization requests I receive are simply automation of a series of commands that the users are tired of doing repeatedly. These customizations can be efficiently completed and easily distributed with VBA. Even the slightly more complex customizations can be nicely handled with VBA in my experience.

The difference comes down to compiled vs interpreted code in my estimation. The .NET version is compiled and therefore will perform better, but will need to be recompiled with every modification. VBA is interpreted (it may be compiled to some level but semantically it is scripting and to me that means interpreted) so the performance isn't as good as .NET but development and distribution is simple and in general most tasks won't notice the hit in performance.

So, I have yet to develop any customizations in .NET. This may make me biased in my opinion, but I would welcome a constructive argument on this because I have not been able to justify tackling the learning curve in moving to .NET. If someone can make a compelling case I would gladly move to it (I develop almost all other programs in .NET).

Denis Message was edited by: Discussion Admin

[Anonymous]

it would seem Tony answered it in his first post. 04 has no net and 05 was
week. The OP need both of these.

--
gl - Paul
wrote in message news:5137891@discussion.autodesk.com...
Did anyone actually answer your question ?
I have also asked this question on this forum and gotten similar replies.
Here is what I think:

.NET is more powerful, versatile and can give you better performance.

but

You have to compile and then install the resulting code on all of your CAD
stations. This may be simple if you have a domain with Active directory,
but if you need to go to each station to do this it may not be worth it.

Most customization requests I receive are simply automation of a series of
commands that the users are tired of doing repeatedly. These customizations
can be efficiently completed and easily distributed with VBA. Even the
slightly more complex customizations can be nicely handled with VBA in my
experience.

The difference comes down to compiled vs interpreted code in my estimation.
The .NET version is compiled and therefore will perform better, but will
need to be recompiled with every modification. VBA is interpreted (it may
be compiled to some level but semantically it is scripting and to me that
means interpreted) so the performance isn't as good as .NET but development
and distribution is simple and in general most tasks won't notice the hit in
performance.

So, I have yet to develop any customizations in .NET. This may make me
biased in my opinion, but I would welcome a constructive argument on this
because I have not been able to justify tackling the learning curve in
moving to .NET. If someone can make a compelling case I would gladly move
to it (I develop almost all other programs in .NET).

Denis

Message was edited by: Discussion Admin

[jbooth]

It's quite easy to make a COM object in .NET that you simply call using VBA, regardless of what version of AutoCad is running. The real limit is whether or not your version has access to VBA. If it does, you can simply import the type library you create using .NET.

Why would you want to do this? It depends on what you want to do. .NET can do everything that VBA can do; it simply uses a different syntax. It is even possible to run old VBA code by using one of the predefined .NET classes. You gain access to the advanced tools .NET has to offer.

The big advantage of using VBA is that you can write code for any version of AutoCad later than 2000 inside the application. You then simply run the code you need through a macro. With .NET to do the same thing you need to learn how to write a COM class, and how to register it before you can call it from AutoCad. ie: it is much more difficult.

Simply put, if you don't need the .NET library for anything, and don't expect to, go ahead and use VBA. I doubt Autodesk will remove the VBA ide from their applications any time soon - quite a few people would decide not to upgrade if they did.


btw, part of the original poster's question asked what the advantages/disadvantages are for VBA/.NET. I only wanted to point out that it is possible to use .NET on any version of AutoCad that supports VBA, and that VBA is not your only option.

[Anonymous]

The AutoCAD .NET API available post 2005 is more powerful than the ActiveX API and is the reason I promote using .NET. I don't see the gain in using .NET if you are still going to use the ActiveX API as I believe some are.

Regards - Nathan

[Anonymous]

this is using .net the same as VB6. I thought the OP was asking
about using the .net libraries not activex.

--
gl - Paul
wrote in message news:5138211@discussion.autodesk.com...
It's quite easy to make a COM object in .NET that you simply call using VBA,
regardless of what version of AutoCad is running. The real limit is whether
or not your version has access to VBA. If it does, you can simply import the
type library you create using .NET.

Why would you want to do this? It depends on what you want to do. .NET can
do everything that VBA can do; it simply uses a different syntax. It is even
possible to run old VBA code by using one of the predefined .NET classes.
You gain access to the advanced tools .NET has to offer.

The big advantage of using VBA is that you can write code for any version of
AutoCad later than 2000 inside the application. You then simply run the code
you need through a macro. With .NET to do the same thing you need to learn
how to write a COM class, and how to register it before you can call it from
AutoCad. ie: it is much more difficult.

Simply put, if you don't need the .NET library for anything, and don't
expect to, go ahead and use VBA. I doubt Autodesk will remove the VBA ide
from their applications any time soon - quite a few people would decide not
to upgrade if they did.


btw, part of the original poster's question asked what the
advantages/disadvantages are for VBA/.NET. I only wanted to point out that
it is possible to use .NET on any version of AutoCad that supports VBA, and
that VBA is not your only option.

[Anonymous]

Hi Nathan,

Could you expand on "more powerful"?

It sounds a wonderful ambit claim, but how is it actually invoked?

Does the power become apparent to the user - or the programmer?
I ask this question in particular, because our Advanced Road Design program
written in VBA with VB6 DLLs runs so much quicker than AutoCAD's equivalent
processes in Civil 3D that it is not even vaguely funny.

Does it compute and draw objects in AutoCAD significantly quicker than VBA
or lisp?

Does it extract information from a drawing and make it available in another
format significantly quicker than VBA or lisp?

Does it enable the programmer to develop an interface more rapidly than
VBA/VB?
(I won't include lisp in this question for obvious reasons)

Does it provide help files related to the AutoCAD interface to help the new
user get started?

Is there any significant quantity of sample code relative to AutoCAD
available, and from where?

I know it does lots of other things which you can't do easily with VBA or
lisp, but which of those things are significant to an AutoCAD customiser?

Tony Zanzillo mentioned in one of his posts (while continuing his
denigration of VB/VBA programmers as distinct from the tools they use), that
the algorithms and code are very important. Is it possible the .NET will
provide an environment where the algorithms are "improved" despite the
programmer?

Does the error handling in .NET improve significantly on what is available
in VB/VBA?

Is it easier for the programmer to invoke error handling?

I'd ask these questions of Tony as well, but he is incapable of answering
with a fact as distinct from personal abuse.

--

Regards,


Laurie Comerford
www.cadapps.com.au


wrote in message news:5138253@discussion.autodesk.com...
The AutoCAD .NET API available post 2005 is more powerful than the ActiveX
API and is the reason I promote using .NET. I don't see the gain in using
.NET if you are still going to use the ActiveX API as I believe some are.

Regards - Nathan

[Anonymous]

I haven't got time to answer all your questions and Tony probably will anyway.

.NET has structured error handling aswell as unstructured like VBA. Structured is a vast improvement over unstructured. Here Is how it works:

Try
'Do stuff that might poduce error
Catch
'React to exception
Finally
'Do stuff whether or not there is an exception
End Try

There is a bit more to it such as the Catch statement can have parameters and there can be multiple catch statements.

One thing the .NET API has is a Jig class that allows you to do dynamic graphic manipulation. This is a major nuisance with my VBA routines and I had tried many workarounds but they all had side effects I was not happy with and were very complex.

There is now also a .NET API for the CUI.

Regards - Nathan

[Anonymous]

".....There is now also a .NET API for the CUI."

OH Boy!