topic Re: .net vs vba ?? in .NET Forum

.net vs vba ??

Anonymous — Thu, 20 Dec 2007 15:32:44 GMT

I am considering learning .net / and or VBA, I am getting direction to go
with .net.
Can anyone tell me the differences between the two? i.e. is .net way
harder, but more powerfull?
Does .net have all the same functionality as vba?

Thanks a million, - a newbie to vb

Re: .net vs vba ??

dgorsman — Thu, 20 Dec 2007 15:50:27 GMT

Way harder, but definitely more powerful. If you haven't done so already, check here:

http://forums.augi.com/showthread.php?t=67675

Your choice of what to do will depend on what your objective is. Are you going to be a software developer, making add-on packages/extensions for sale? Are you going to be a CAD support person, customizing AutoCAD to support a companies internal needs and maintaining its current system? Are you "just a user" (no offense, can't think of a better term) looking for a few extra shortcuts to make your own work processes faster?

Naturally, if you ask in the .NET area, most responses will be to promote .NET, rather than VBA. Same thing in the VBA area, but with a lower percentage. Message was edited by: dgorsman

Re: .net vs vba ??

Anonymous — Thu, 20 Dec 2007 17:09:37 GMT

And a lot more easier to crash AutoCAD, if your programming skill is not up
to "professional level".

"dgorsman" wrote in message news:5805929@discussion.autodesk.com...
Way harder, but definitely more powerful. If you haven't done so already,
check here:

http://forums.augi.com/showthread.php?t=67675

Your choice of what to do will depend on what your objective is. Are you
going to be a software developer, making add-on packages/extensions for
sale? Are you going to be a CAD support person, customizing AutoCAD to
support a companies internal needs and maintaining its current system? Are
you "just a user" (no offense, can't think of a better term) looking for a
few extra shortcuts to make your own work processes faster?

Naturally, if you ask in the .NET area, most responses will be to promote
.NET, rather than VBA. Same thing in the VBA area, but with a lower
percentage.

Message was edited by: dgorsman

Re: .net vs vba ??

jbooth — Thu, 20 Dec 2007 17:57:41 GMT

If you learn VBA you will be limited (mostly) to programming with Autocad, Word, Excel, etc...

If you learn .NET you will not have this limitation, but you will have more difficulty accessing the Autocad API. However, if you learn how to create and manipulate activeX objects, you can do just as much as if you were using VBA.

It's up to you how far you want to go. If you want to write Autocad macros use VBA. The Autocad VBA package can do most of the things that most people want done when it comes to Autocad. If you want to use the extensive .NET libraries to do more involved things (ex: create web components or database connections) use .NET.

Most importantly is that using .NET doesn't necessarily mean you need to use the ObjectARX .NET managed wrappers. You can easily use COM interop and write code similar to what would be seen in Autocad VBA.

Too bad you have to buy Visual Studio in order to use .NET. 🙂

Re: .net vs vba ??

Anonymous — Thu, 20 Dec 2007 19:03:47 GMT

For starters, my advice would be to not put too much stock in the AUGI thread you were pointed you to, because the participants make it clear in that thread, that they're somewhat misinformed, and its also a known fact that some of them have little-to-no practical experience with .NET, which means they are basically guessing and speculating, and are unable to offer a qualified opinion.

It isn't always a question of what is 'easier'. It's also a question of what is the best investment in terms of the future.

I fully expect a large number of AutoCADs to be running on 64 bit machines in the not-too-distant future, mainly because of its ability to address greater amounts of RAM, and the many benefits that offers to AutoCAD users, most of whom are pushing their current 32 bit hardware to its limits.

Microsoft has already made it clear that there will be no port of VBA to 64 bit, and if we consider just that one simple fact, I think the choice is a no-brainer. The 'hack' that Autodesk and others have resorted to in 64 bit versions of their applications, essentially amonts to running VBA as a seperate 32-bit process, which means that performance suffers to the extent that any use of VBA is like dragging around a ball and chain, and completely unacceptable for most.

If you look in the VBA newsgroup, you will see many who experience the same set of common problems, and the kind of 'kludges' they are forced to use to work around them. Some of them are not only ugly, but they also don't work all of the time, and only tend to create as many or more problems than they attempt to solve.

For example, .NET lets you use the AutoCAD command line in the exact same way you can with LISP's (command) function, which for many things, represents the shortest distance between two points, and a much easier way to just get something done without all the headaches you have doing the equvalent in VBA with it's hideous 'SendCommand' kludge-o-rama.

Another important factor is that .NET allows you to use the same ActiveX API that VBA uses, which means that you can use it from .NET and avoid the more difficult-to-use managed ObjectARX API until you are comfortable with it. You can also freely mix both ActiveX and managed APIs in the same code, which means that you can gradually tap into the managed API in small and measured ways, and use it to solve problems that ActiveX doesn't offer good solutions for.

What that means is that with .NET, you have access to the best features and aspects of each of AutoCAD's APIs, rolled into one seamless environment:

1. The ability to script the command line easily
and synchronously as you can do from LISP.

2. Access to the same ActiveX API that VBA is based on.

3. Access to the much more powerful managed ObjectARX
API for cases where its power is warranted.

Finally, you also have all the power which the .NET framework offers for all types of development, like much richer user interfaces; database access; internet and XML development, and you get that without any of the hideous 'baggage' that comparable ActiveX-based applications written in VB or VBA must tow around with them.

Is the VB.NET language more difficult to learn than VBA? I don't think it is.

Many people tend to confuse languages and the APIs used with them. In terms of the language alone, VB.NET was designed to make it easy for VB programmers to migrate to, and isn't much more difficult to learn.

However, the .NET framework is a very large _API_ that VBA does not have access to in the first place. And yes, learning to use that API is certainly something that VBA programmers don't have to contend with. Learning to drive a Formula 1 race car also takes longer than learning to ride a three-wheeled tricycle.

As far as VBA goes, I would summarize it thusly:

"No pain, no gain".

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com

Re: .net vs vba ??

Anonymous — Fri, 21 Dec 2007 00:09:29 GMT

>Too bad you have to buy Visual Studio in order to use .NET. 🙂

No you don't. I use the free SharpDevelop and am able to code up .Net (C#) to use within Acad.

http://www.icsharpcode.net/OpenSource/SD/

Re: .net vs vba ??

Anonymous — Fri, 21 Dec 2007 00:25:05 GMT

SharpDevelop is great, and there also the Express versions of Visual Studio that are free as well.

No one else has mentioned it but if you're going to go the .NET route rather than VBA I would recommend going with C# rather than VB.NET it's not really that much more complicated and you get even alot more benefit from C# than you with VB.NET, let alone you will find alot more Autocad examples in C# than VB.NET

But either one is fine.

Re: .net vs vba ??

Anonymous — Fri, 21 Dec 2007 11:55:33 GMT

If you're ready to start learning vb.net you can get started at no cost.

Download the vb.net express edition for free from microsoft, and check out kean's blog post on debugging autocad with .net express editions. Threre are some really good AU handouts on vb.net. All links are in the following post.

http://civil3dblog.com/2007/12/01/autocad-civil3d-debugging-with-net-express/

If you do start out learning VBA most of your coding experience can be moved over to vb.net. I started out coding standalone vb.net applications. Simple engineering calculations, channel flow, etc. This really helped me learn visual basic in general. There are a lot of samples out there. Come up with an idea that you want your application to do and get started. If you need help there are lots of vba/.net discussion groups. Don't be afraid to stray beyond the autodesk groups. There are a lot of people out there willing to help.

Good luck, happy coding.

Re: .net vs vba ??

Anonymous — Fri, 21 Dec 2007 15:07:20 GMT

Thanks Tony!

What about the vb.net versus c++.net thing?

--
Robert Quinn
President RCM,Inc., Revcam, LLC, Heliforming Technologies
Tel: 586-336-1237
Fax: 586-336-1287
"Tony Tanzillo" wrote in message
news:5806149@discussion.autodesk.com...
For starters, my advice would be to not put too much stock in the AUGI
thread you were pointed you to, because the participants make it clear in
that thread, that they're somewhat misinformed, and its also a known fact
that some of them have little-to-no practical experience with .NET, which
means they are basically guessing and speculating, and are unable to offer a
qualified opinion.

It isn't always a question of what is 'easier'. It's also a question of what
is the best investment in terms of the future.

I fully expect a large number of AutoCADs to be running on 64 bit machines
in the not-too-distant future, mainly because of its ability to address
greater amounts of RAM, and the many benefits that offers to AutoCAD users,
most of whom are pushing their current 32 bit hardware to its limits.

Microsoft has already made it clear that there will be no port of VBA to 64
bit, and if we consider just that one simple fact, I think the choice is a
no-brainer. The 'hack' that Autodesk and others have resorted to in 64 bit
versions of their applications, essentially amonts to running VBA as a
seperate 32-bit process, which means that performance suffers to the extent
that any use of VBA is like dragging around a ball and chain, and completely
unacceptable for most.

If you look in the VBA newsgroup, you will see many who experience the same
set of common problems, and the kind of 'kludges' they are forced to use to
work around them. Some of them are not only ugly, but they also don't work
all of the time, and only tend to create as many or more problems than they
attempt to solve.

For example, .NET lets you use the AutoCAD command line in the exact same
way you can with LISP's (command) function, which for many things,
represents the shortest distance between two points, and a much easier way
to just get something done without all the headaches you have doing the
equvalent in VBA with it's hideous 'SendCommand' kludge-o-rama.

Another important factor is that .NET allows you to use the same ActiveX API
that VBA uses, which means that you can use it from .NET and avoid the more
difficult-to-use managed ObjectARX API until you are comfortable with it.
You can also freely mix both ActiveX and managed APIs in the same code,
which means that you can gradually tap into the managed API in small and
measured ways, and use it to solve problems that ActiveX doesn't offer good
solutions for.

What that means is that with .NET, you have access to the best features and
aspects of each of AutoCAD's APIs, rolled into one seamless environment:

1. The ability to script the command line easily
and synchronously as you can do from LISP.

2. Access to the same ActiveX API that VBA is based on.

3. Access to the much more powerful managed ObjectARX
API for cases where its power is warranted.

Finally, you also have all the power which the .NET framework offers for all
types of development, like much richer user interfaces; database access;
internet and XML development, and you get that without any of the hideous
'baggage' that comparable ActiveX-based applications written in VB or VBA
must tow around with them.

Is the VB.NET language more difficult to learn than VBA? I don't think it
is.

Many people tend to confuse languages and the APIs used with them. In terms
of the language alone, VB.NET was designed to make it easy for VB
programmers to migrate to, and isn't much more difficult to learn.

However, the .NET framework is a very large _API_ that VBA does not have
access to in the first place. And yes, learning to use that API is certainly
something that VBA programmers don't have to contend with. Learning to drive
a Formula 1 race car also takes longer than learning to ride a three-wheeled
tricycle.

As far as VBA goes, I would summarize it thusly:

"No pain, no gain".

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com

Re: .net vs vba ??

Anonymous — Fri, 21 Dec 2007 16:41:40 GMT

It's mostly a personal preference, but I've always recommended C# for someone that is new to programming and has no prior experience with VB.

There are several reasons for that.

First, you will find more and better quality source code and examples written in C#, because it is the overwhelming choice of more experienced and professional programmers, most of whom have prior, extensive C++ experience. IOW, people who write code for a living, generally choose C# as their .NET langauge.

The other reason relates to another aspect of learning .NET, which is its object oriented nature. and the fact that .NET is an object-oriented API. Both VB.NET and C# are true object-oriented programming langauges. Taking full advantage of either requires a reasonable understanding of the basic principles and concepts of OOP. VBA and VB6 only 'flirt' with those concepts, and are not true OOP langauges, so a big hurdle in transitioning from either of those languages to any .NET langauge, is learning OOP concepts.

If you're just starting out, IMO, it's far easier to grasp the basic concepts of OOP with C#, as compared to VB.NET. So, if you've never coded in any form of VB, my advice is to go the C# route.

Additionlly, the latest version of C# uses functional programming to a greater extent (Functional programming is where code or functions that contain code, is treated just like other kinds of data). Since LISP is the premere functional programming langauge, if you are coming from a LISP background and are reasonably familiar with LISP's functional programming aspects (e.g, things like the (mapcar) and (foreach) fuctions), you can apply those same concepts in C#:

For example:

(setq mylist '(100 200 300 400))

(setq result (mapcar '(lambda (x) (+ x 1)) mylist))

(print result)
-> (101 201 301 401)

In C#:

List mylist = {100, 200, 300, 400}; // C# 3.0 only.

List result = mylist.ConvertAll(delegate(int x) {return x+1;});

Console.WriteLine(result.ToArray().ToString());

-> {101, 201, 301, 401}

In the above, these are functionally equivalent:

(lambda (x) (+ x 1))

delegate(int x) { return x + 1;}

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com

"Bob Quinn" wrote in message news:5806834@discussion.autodesk.com...
Thanks Tony!

What about the vb.net versus c++.net thing?

--
Robert Quinn
President RCM,Inc., Revcam, LLC, Heliforming Technologies
Tel: 586-336-1237
Fax: 586-336-1287
"Tony Tanzillo" wrote in message
news:5806149@discussion.autodesk.com...
For starters, my advice would be to not put too much stock in the AUGI
thread you were pointed you to, because the participants make it clear in
that thread, that they're somewhat misinformed, and its also a known fact
that some of them have little-to-no practical experience with .NET, which
means they are basically guessing and speculating, and are unable to offer a
qualified opinion.

It isn't always a question of what is 'easier'. It's also a question of what
is the best investment in terms of the future.

I fully expect a large number of AutoCADs to be running on 64 bit machines
in the not-too-distant future, mainly because of its ability to address
greater amounts of RAM, and the many benefits that offers to AutoCAD users,
most of whom are pushing their current 32 bit hardware to its limits.

Microsoft has already made it clear that there will be no port of VBA to 64
bit, and if we consider just that one simple fact, I think the choice is a
no-brainer. The 'hack' that Autodesk and others have resorted to in 64 bit
versions of their applications, essentially amonts to running VBA as a
seperate 32-bit process, which means that performance suffers to the extent
that any use of VBA is like dragging around a ball and chain, and completely
unacceptable for most.

If you look in the VBA newsgroup, you will see many who experience the same
set of common problems, and the kind of 'kludges' they are forced to use to
work around them. Some of them are not only ugly, but they also don't work
all of the time, and only tend to create as many or more problems than they
attempt to solve.

For example, .NET lets you use the AutoCAD command line in the exact same
way you can with LISP's (command) function, which for many things,
represents the shortest distance between two points, and a much easier way
to just get something done without all the headaches you have doing the
equvalent in VBA with it's hideous 'SendCommand' kludge-o-rama.

Another important factor is that .NET allows you to use the same ActiveX API
that VBA uses, which means that you can use it from .NET and avoid the more
difficult-to-use managed ObjectARX API until you are comfortable with it.
You can also freely mix both ActiveX and managed APIs in the same code,
which means that you can gradually tap into the managed API in small and
measured ways, and use it to solve problems that ActiveX doesn't offer good
solutions for.

What that means is that with .NET, you have access to the best features and
aspects of each of AutoCAD's APIs, rolled into one seamless environment:

1. The ability to script the command line easily
and synchronously as you can do from LISP.

2. Access to the same ActiveX API that VBA is based on.

3. Access to the much more powerful managed ObjectARX
API for cases where its power is warranted.

Finally, you also have all the power which the .NET framework offers for all
types of development, like much richer user interfaces; database access;
internet and XML development, and you get that without any of the hideous
'baggage' that comparable ActiveX-based applications written in VB or VBA
must tow around with them.

Is the VB.NET language more difficult to learn than VBA? I don't think it
is.

Many people tend to confuse languages and the APIs used with them. In terms
of the language alone, VB.NET was designed to make it easy for VB
programmers to migrate to, and isn't much more difficult to learn.

However, the .NET framework is a very large _API_ that VBA does not have
access to in the first place. And yes, learning to use that API is certainly
something that VBA programmers don't have to contend with. Learning to drive
a Formula 1 race car also takes longer than learning to ride a three-wheeled
tricycle.

As far as VBA goes, I would summarize it thusly:

"No pain, no gain".

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2008
Supporting AutoCAD 2000 through 2008
http://www.acadxtabs.com