Which API?

First, I apologize for "cross-posting" this but since I'm asking general
questions about mulitipe Adesk API's I thought it would
be appropriate in this case.

Basically, Im looking for input on what would be the best API for me to
devote my time to. I've been using Lisp for years now
but recently started using VBA (I had to if I wanted to tinker with
Inventor). I avoided vba for a long time because it seemed
so "foreign" to me, with the dot syntax and all. After just a week of
VBA'ing though, I've grown to love it.
Its MUCH easier than Lisp, much more intuitive, much easier to read,
maintain and debug. It also seems much faster. So now I scorn
Lisp for anything but the simplest of macro's.
My intent, after completing my first major project with VBA was to "port" it
over to standalone VB6. Now though Im wondering,
since Im embarking on a new (to me) language should I just skip the vb6 step
and go to VB.net? In that same vein, should I just
skip VB altogether and go to C-sharp?
I avoided C for a long time too after tinkering with it a bit several years
ago, it seemed that to build even a simple
acad addon with C required a PhD in computer science so that you could first
master C then grapple with the rather large
libraries composing the object arx system.
At a glance, the learning curve for Arx programming looked very much like
the Eifel tower. Needless to say I gave up on that

approach, I didnt have the time (and money) to spend so much trying to learn
it, especially when Lisp (and later vb) were SO much
easier.
I have heard though that C sharp is considerably easier to master that C/C++
and so assume arx programming should be a bit
less painful as well, and apparently the Arx system is moving in that
direction.

In a nutshell then is my question, should I stick with VBA, go to VB6, go to
VB.net or take the plunge into C sharp?
To give this question a little perspective, here are my requirements:

1. Most important, the one thing I miss from Lisp is the ability to create
what appear to be "native" commands, i.e. (defun

c:mycommand) this isnt possible with vba, and I assume its not with vb6. It
is possibe with C, but what about VB.net or C sharp?

2. The ability to create custom entities would be real nice, been wanting to
do that for a long time. Obviously this cant be
done with Lisp or VBA. Last I heard it could only be done with C++/Arx. Can
the .Nets do it? VB or C?

3. It would be nice if I could create code that would be compatible all the
way back to Acad2000, this of course will
sometimes be impossible. Im under the impresson that only Acad2005 supports
VB.net, although I thought I heard someone
say they were doing .net with Acad2004. I have also heard that Inventor only
partially supports .net right now.

4. Lastly, as you may have gathered, I also want to create apps/utilies for
Inventor, thats what got me into VB in
the first place.

As an aside, if I decide to use VB6, how is the executable to be compiled,
as an activeX.dll? activeX.exe? neither?
How are functions inside this executable called from within Acad? I assume
the "vbarun" construct will not work.
Is the process similair for VB.net?
I have found tons of helpfull VBA projects on the net but have not as of yet
found any examples of "standalone"
apps/utilities designed for Acad. Are there any examples out there?

Thanks much for any tips

 

The quick answer is; all of them I am currently working on a project
that has code written in four languages and developed in five environments.
(A lot of that is inherited legacy code and I am working to cut at least two
of those out).

So learn about each tool. How much you learn of each depends on a lot of
factors. You hit on a big one with C++ and ARX in that it takes a
considerable amount of time and effort to gain the power that resides there.
However, if you plan on developing professional applications for AutoCAD,
then this is a completely viable, and arguably necessary, route to go.
There are those here that are much more qualified than I to expound upon the
virtues of C++ and ARX. Hopefully one or more will chime in.

The .NET managed environment is easier to grasp than unmanaged C++. The
biggest areas of improvement are in memory management and GUI creation. VB
users will note that these are areas that they've enjoyed ease of use with
for many years. Of course .NET has more to offer than that, like the
framework's class library and the ability to pick and choose your language
of choice. You mention that you may want to skip VB.NET and go directly to
C#. In the managed .NET world, this doesn't really make sense. While the
languages are syntactically different, they both target the .NET framework
and they both compile down to the same intermediate language. Managed C#
doesn't offer the same advantages that over VB.NET that C++ does over VB6.
Not to say that you shouldn't choose C# (I did), just don't think that by
going with C# you are skipping VB.NET and gaining a vastly more powerful
platform.

The one side note is that you'll want to keep your eye on the AutoCAD .NET
API. It may never completely encompass all of the ARX libraries, but it's
going to get closer and closer over the next few releases. See further
comments inline below.

[BCJ] It is possible to easily create native commands with the .NET API in
2005. Anything earlier than 2005 will require a lisp wrapper. VBA and VB6
apps will require a lisp wrapper even in 2005.

[BCJ] You will still need C++/ARX to do this as of 2005.

[BCJ] This isn't easy no matter what your language.

[BCJ] Only Acad 2005 has a .NET API. You can still develop for older
version with .NET, you just have to do it via COM Interop.

[BCJ] Inventor currently has a COM API. And as I said before, that's the
extent of my Inventor knowledge

[BCJ] The answers to those questions are project dependent and can only be
answered by you. You will likely have some projects that have both dll's
and exe's.

[BCJ] One way to do it with VB6 is to create an ActiveX DLL and then create
a lisp wrapper that loads it via the AutoCAD application objects
GetInterfaceObject method. Then you can invoke your DLL's methods and
properties. This process is similar with .NET, although a bit more involved
as you have to specifically prep your .NET code for COM Interop. With .NET
in 2005 the process is much simpler as you can create commands directly,
without the need for the lisp wrapper.

[BCJ] There's not really anything magical about creating the code in a
"standalone" environment. The main difference is that projects created in
"standalone" environments aren't automatically loaded in process with
AutoCAD like VBA apps and you don't have access to the ThisDrawing object.
With VB6, or .NET apps run on AutoCAD prior to 2005, you'll need to
determine which projects need to run in process with AutoCAD, or even which
parts of the project, and get them loaded. After that, code performing the
same operation would be almost identical in VBA and VB6.

HTH

 

Thanks Bobby for your exhaustive answer to my long-winded question!
I mentioned that I might skip over VB6 and go straight to VB.net, which may
be a better choice (native commands) but limits
my potential market since not everyone is on the latest version of Acad.
On the other hand Im not too crazy about making lisp "wrappers" for VB
functions. I am aware that VBnet and C# compile
down to the same "binary" (clr) and thats why I questioned futher "skipping"
of VBnet and going to C#. But if C# doesnt offer
any real advantages over vbnet why bother with its higher learning curve.
I see also that if I want to create custom entities I would still have to go
the ARX route, just have to convince my
employer to give me a 2 year sabbatical to learn it!
Looks like I will have to make some serious compromises no matter what route
I take, except for the arx route, but that will
compromise much time. Sure would be nice if .NET could do custom entities,
it would make it easier to justify leaving behind
pre-2005 Acad users.
Any other C or .Net gurus want to chime in?
Thanks

 

What language/API to choose is not really the question you
need to be asking yourself. What you need to ask yourself is
what do you need to make effective use of any of them.

Unlike LISP and VB6, True OOP languages like .Net; C++; Delphi,
and most other modern, object oriented programming languages
require the VB6 or LISP programmer to learn new, fundamental,
key concepts and principles of real OOP, most if not all of
which are entirely foreign to LISP and VB.

Many who wear C# on their sleeve and say they use it, do so in
a relatively unsophisticated way, and that's primarily because
they're VB 'programmers' who just recently jumped ship, still
'wet behind the ears', and don't yet fully understand some of
the key OOP principles and concepts, or how to properly apply
them in real world development.

Hence, they generally use C# like it was a supercharged VB6,
in a non-object oriented way, where the code they write is
mostly a client or consumer of existing classes rather than an
implementer/provider of classes.

That's almost exactly how it went for me, when I began using
Delphi about 10 years ago. Initially, I used Delphi as though
it were just a 'turbocharged' Visual Basic (in other words, I
wrote code that primarily consumed classes of the VCL Framework,
but did not implement my own code in classes).

Over the course of those 10 years I gradually learned OOP and the
principles it is founded on. As a result, today I can do really
cool things using OOP (in Delphi, C++, and C#).

With the exception of some concepts like multiple inheritance
and generics (templates in C++), which are to this point the
exclusive domain of C++, most of the other fundamental OOP
concepts that I've had to learn and embrace in the course of
using Delphi and C++ for past 10 years, are equally applicable
to C# and any other real OOP language.

So, it's really not so much about what OO language you use.
Rather, it's the fact that using any of them effectively
requires a good understanding of the key concepts of OOP.

Once you understand those software engineering concepts and
have a solid foundation in OOP; class design and best practices
in coding, underpinnings of all OO languages, then you will
be able to learn to use just about any of them with relative
ease (I use them all, except VB.Net, which I detest).

You'll undoubtedly come across many recent VB-to-C# converts
who now proudly wear C# on their sleeves and claim they are
now 'better' programmers because they use a real OOP. But in
many cases, they're using those languages as a souped-up VB6,
with the same old, flawed ideas. Hence they're just beginning
to learn the basics of OO; class design; and how to exploit
key concepts like polymorphism, inheritance, and persistence.

The fact that you use an OOP language, doesn't necessarily
mean you're using it in the way it was intended to be used,
that only comes with years of experience with it.



AutoCAD based Security Planning Solutions:
http://www.caddzone.com/securityplanning

 

Oh my, mark this one down, a topic that Tony and I can agree upon.

The language C# isn't any harder to learn than VB. It may seem harder
because you are already familiar with how to declare variables and build
program flow structures and such in VB. But that's basic language syntax
and is the stuff that is covered in the first 3 or 4 chapters of any book
that you can pick up. Don't get me wrong, I don't mean to trivialize
learning language syntax, but that's the easy part of programming.

The hard part is just as Tony stated, learning to design a program so that
it is easy to understand, maintain, re-use, and grow. OOP is a design
methodology that addresses these issues. And it is vastly different than
coding in LISP or VB. This is the hard part to learn and you'll need to
learn this no matter the language that you choose.

When Tony says that it's taken him ten years to take advantage of OOP, I
fully believe that. I've never seen any of Tony's code other than the short
procedures that he shares here in the groups, but I imagine that it's good
solid OO code and is based on his many years of experience. I myself only
learned of such things as design patterns a few short years ago and I still
find myself thinking in "action oriented" structured programming terms on
occasion. It's not been easy for me to make the switch. So when I choose
C# over VB.NET it was a mental change of attitude on my part. In with the
new, out with the old. I knew that if I went the VB route, I was more
likely to drag old structured habits right along with me. Frank Oquendo was
the one to advise me early on. He had recently started working with .NET
and had gone the C# route.

So if you have more mental fortitude than I, which isn't all that difficult,
you can just as easily stay with VB and learn good OOP as you could by
learning C#. But the choice is yours and the reasoning behind that choice
shouldn't be based on language syntax. .NET has really leveled the field as
far as that goes. Even if you decide that you need to learn C++ you can dip
your toes into the managed world and get comfortable there and then make the
dive into unmanaged C++ and on into ARX programming.

Good luck Perry!

 

Thanks for the excellent input guys.
Now Im starting to lean in the C# direction. This could have the added
benefit that once I feel comfortable with it, if I REALLY need some of the
power of C++ then perhaps it wont be so difficult if I have a solid footing
in the sharp domain.
As Tony stressed, perhaps the most important thing to do would be "unlearn"
everything I've learned from Lisp and VB and approach C#
with a clean slate so the new concepts wont be fighting against old habits.
Wiping the slate clean (between my ears) should'nt be too hard
as I sometimes do it unintentionally
This leads me to yet another question:
In the new MS studio C++ ship along with C# and VBnet so should I assume
that its C++ code compiles down to the "same" type of binaries
(clr) as do C# and Vb.net? If so, then why is C++ so much more powerful, it
would seem that any of these languages should be able to accomplish
any task that any other of them could accomplish. Why can C++ create custom
entities but not C#? is it because the ARX libraries can be linked up
with C++ but not sharp? if thats the case it seems that any of these
languages could implement ARX if "wrappers" were written.
Is my reasoning here out in left field?
In essence, to boil all of this down to one question its "if Im going to
invest considerable time and effort into learning a new language, whats
going to give me the most bang for my buck" not just in terms of ease of
use, but power and flexibility.
At 45, I dont think I have the time to become "expert" in several !

Thanks again guys!

 

In the new MS studio C++ ship along with C# and VBnet so should I assume

it

[BCJ] The C++ compiler compiles code targeted for a specific platform. Once
compiled this code is directly machine executable on the target platform.
This is the technology that AutoCAD and the ARX libraries are based on.

C# and VB.NET do not compile down to machine readable code. They compile
down to the Microsoft Intermediate Language, MSIL for short, or IL for even
shorter . Then the Common Language Runtime portion of the .NET
Framework takes the IL and converts it to machine readable code on the fly
as it's executed. IL is "managed" by the CLR, hence the term Managed Code.
Note that you actually have the option with C++ to go managed or unmanaged.

[BCJ] That is correct. On both counts. ARX/DBX apps that you write must
link up to the unmanaged C++ libraries provided by Adesk and MS, and managed
code cannot do that. Although .NET wrappers do not currently exist to allow
us to create custom Acad entities, I'd be willing to bet the farm that they
will in the future. Note that I don't actually have a farm although the
kids can act like little animals on occasion.

[BCJ] In the bigger picture, language aside, you will get the most bang for
your buck by learning OOP techniques. If you absolutely must have custom
entities and complete access to all that the ARX libraries offer right now,
then C++ is your only option. If you have the luxury of being able to learn
OOP at your own pace and can wait on full access to ARX, then a .NET
language is an option.

It sounds like your already assessing your needs and doing your homework.
I'm sure that you'll be satisfied whichever route(s) you decide to travel.

 

Thanks Bobby !

--
Perry Leets
Inovec Optimization and Control Systems
Eugene, Oregon

 

In Visual Studio.NET, There are two types of C++,
Managed, and Unmanaged. Managed C++ generates
managed code (e.g., the same thing that C# and
VB.NET generate). Unmanaged C++, which is all
there was in earlier releases of Visual C++,
generates .lib files that are linked into native
machine code.

VC++.NET can also create mixed mode binaries
that can contain both managed and unmanaged
code.



AutoCAD based Security Planning Solutions:
http://www.caddzone.com/securityplanning

 

Thanks for clarifying that Tony

 

My reply is from a different perspective - I only just started learning C# a couple of days ago, although over the years I've used everything from 68000 assembler to Forth to C to Pascal to AutoLisp and of course countless varieties of Basic.

Why did I choose C#? Simply because that seems like the direction Autodesk and others are heading at the moment, so there will be more examples and support available. That's an advantage even if my apps end being mostly just consumers of existing classes, rather than taking full advantage of OO programming as Tony mentioned.

Best thing that has helped me so far? Ignoring MS Visual Studio and instead writing code in Notepad and compiling at the command line. For me, it's a way of ignoring the glitter & flash and instead concentrating on the core language. When I get to the point of creating more elaborate UI's then of course I'll head back to Visual Studio, but I want a better grounding in the language first.

...Colin French

 

Using an object framework generally requires you to implement
your own classes. You can't be simply a consumer and only a consumer.

For example, every time you create a Form or UserControl in C#,
you are implementing a custom class. The fact that the IDE generates
the skeleton implementation code for it, is coincidental.



AutoCAD based Security Planning Solutions:
http://www.caddzone.com/securityplanning

years I've used everything from 68000 assembler to Forth to C to Pascal to AutoLisp and of course countless varieties of
Basic.

there will be more examples and support available. That's an advantage even if my apps end being mostly just consumers
of existing classes, rather than taking full advantage of OO programming as Tony mentioned.

the command line. For me, it's a way of ignoring the glitter & flash and instead concentrating on the core language.
When I get to the point of creating more elaborate UI's then of course I'll head back to Visual Studio, but I want a
better grounding in the language first.