The best way I can describe the differences is VB.NET is a "polished turd".
I agree. Only my opinion, too, of course. Of course, if VB.NET is a "polished turd", C++ must be the raw steaming version...
But to give a serious answer, I simply don't like VB syntax. Some people like it because of the lack of curly braces, but it just irks me. From the DIMs to the LOOPs, I just really hate the syntax. Simply a matter of personal preference.
I've only been using C# for a couple of weeks now, but I have to admit I rather like the language. Maybe not as much as Objective-C, with its categories and protocols and message-based implementation, but it's not bad. And it's SSSOOOOO much nicer than Lisp, which is what I had been using for most of my recent coding. Haven't had enough experience with C# or MSIL to know what I think of them for commercial software development, but they work well for customizing Autocad.
"Tony Tanzillo" <tony.tanzillo@THE_URL_BELOW.com> wrote in message news:<5507199@discussion.autodesk.com>...
- Basic concepts of sofware engineering
- The development tools
- The .NET framework
- The AutoCAD .NET managed wrapper API
for ObjectARX.
Equally as important is the order they appear in....
IOW, trying to do it backwards is just not going
to work
That's true. But for someone who has firm grounding in most of the concepts, the lack of examples and generally-poor state of the documentation - especially for the Civil-3D API - makes things unnecessarily difficult.
I've only been hammering through the .NET API for a couple of weeks now, but I've discovered a lot of things that were a real pain to discover, simply because of the state of the documentation. And then there are a number of things that seem like they should work, but they don't, because of something Autodesk did. And then there's the bugs, and errors in the API, of which I've already found several. So it seems like a good set of examples would serve a lot of common good...
Does anyone have interest in creating a Swamp.NET library? To see what I mean, take a look at the source code on
this page. The three classes in the "AutocadUtilities" directory illustrate the beginnings of a C# Autocad .NET library. The other classes in the project implement four Autocad commands, and illustrate how the library routines are used. All of these particular routines require Civil-3D to run, but the concept holds for all Autodesk products. I know that a lot of people like to keep source code for stuff like this private, but I feel greater value can be realized by distributing it. That way, more people will understand how to create customizations, which will change people's ideas of what they can do with the product, which will result in more good ideas creeping into the public domain, which is good for all Autocad users in general.
A Swamp.NET library would serve a dual purpose - in addition to illustrating how to customize Autocad, and it would also fill in the gaps in Autodesk's API, so that not everyone would have to "reinvent the wheel" so much. That would give people more time to write the USEFUL stuff, rather than fighting through nuts-and-bolts.
At the moment, I've only implemented a small set of functionality. But eventually, it could become a relatively full-fledged library, which we could compile into a "SwampLib.DLL" for general use. Kind of an informal open-source effort, which provides useful utilities to other users, and at the same time serves as an example of how to perform various tasks. For example, since Autodesk did not expose the FeatureLine API in Civil-3D, I went to lots of extra brain-damage in order to figure out how to do basic work with FigureLines. There's no good reason that every other person who wants to customize Civil-3D FeatureLines should have to go through the same brain-damage. Instead, they could just use the CurveUtil routines from the SwampLib.
Don't know if it would be practical or not. It might only work if the library had a single person to work as "editor", otherwise it might deteriorate into chaos. That might be an awful lot of work. And we'd undoubtedly need seperate libraries, one for Vanilla and one for each vertical app, so it might require multiple "editors". Could turn into a lot of effort. But just thought I'd throw the idea out there, and see what people thought. In any case, I intend to keep posting the source code for my Civil-3D utilities on our companies web page, at least for the time being, so there's at least that much for people struggling with the Civil-3D .NET API.