How about you post what you have so far and indicate where you are having trouble.
... I'll have a look tonight .. or someone else will
Thanks, Kerry.
Unfortunately all I have is a windows form application, with one form consisting of a button and a text box.
I've just read C# 2008 for dummies and have another practical exercise manual that I am working through as well.
However, I wanted to spend half an hour a day working on a CAD project, too. So I decided I would create a form that can create a drawing at the press of a button using text specified in a textbox. I then plan to add bits of code to this solution to give myself experience pertinent to AutoCAD development; my main reason for learning C#.
If you're just starting out with C# and .NET, I would recommend focusing
on becoming reasonably proficient with those technologies first, and after
you have a few months (at minimum, but preferably at least a year) of
experience with them, then start with ObjectARX. Sorry if that sounds
discouraging, but doing managed ObjectARX programming without having
those basic prerequisites, is like trying to run before having learned to walk.
What many who've never used it before quickly discover, is that AutoCAD's
managed .NET API is not easy for an entry-level programmer to use, in the
ways that VBA and LISP are. The managed .NET API for AutoCAD requires
a reasonable degree of experience and a good understanding of the basic
tools that are used (mainly C# or VB.NET, and the .NET Framework), and
the concepts that underly them (like for example, a good understanding of
object-oriented programming concepts).
Some seem to think that because there's a visual designer that allows
them to easily create user interfaces using drag-and-drop, that they
don't need to know too much about programming to build a program,
which is not the case.
The user interface is only one part of the puzzle and it's easiest part
thanks to the visual tools, but making the application do something is
another matter, and learning the programming language and APIs that
must be used to do that is a prerequisite to building real software.
The thing that many need to understand about programming, is that
their experience is what allows them to see what's wrong with their
code. If they can't see what's wrong with it, it's common for wishful
thinking to take over, and lead one to incorrectly assume there is
nothing wrong with their app... that is, until it crashes on the user or
corrupts their data. In one case I'm familar with, one inexperenced LISP
programmer was all that was needed to corrupt the infrustructure data
for a medium-sized US city, to the point where it had to be completely
thrown out and recreated from scratch (at a cost of 7 figures), and
ultimately resulted in half their engineering department getting pink slips.