Topic: .NET newbie question

[surveyor_randy]

I'm a longtime VB6 and VBA programmer and I've recently started looking at .NET.  I'm just curious, why would anyone want to write in .NET??  I understand that Autodesk is moving towards .NET only but when I've looked at ways to accomplish things using the API with Autodesk.AutoCAD.Geometry versus using the COM object with Interop, things are 100% harder.  A good example would be offsetting a line. 

To offset a line 50', with COM, you could just:

Dim oTmpLine as AcadObject
Dim oOffsetLine as AcadLine

Set oTmpLine = ThisDrawing.ModelSpace.AddLine(vStart,vEnd)
Dim vObjectArray as Variant
vObjectArray = oTmpLine.offset(50)
set oOffsetLine = vObjectArray(0)

How would you do this with .NET?  I'm sure it couldn't be done in as few lines of code.  Other then speed, why would anyone want to start using .NET or am I making it more complicated then it is?

 

[Nathan Taylor]

The .NET API is more powerful than the ActiveX API. For example when you want to insert a block you can use a jig to display the block while the user selects a point. This can not be done with the ActiveX API. VBA users have developed complex kludges using SendCommand to try and acheive it.

[surveyor_randy]

I understand that it has more power and I really like some of the new objects that have been exposed.  What I don't understand though, is why it is now more difficult to accomplish tasks that used to be simple.  Offsetting a line, creating a new layer, drawing a line, etc...  Maybe I only *THINK* that because I am new to .NET.

[T.Willey]

Maybe its because now you have more control of it.  Like you only write one line of code to use the ActiveX libraries, but what happens behind the screens is a lot of code, and now instead of using those default libraries, you create you own.

/guess

[sinc]

I don't think you're complaining about a .NET thing, I think you are complaining about an Autodesk API thing.

The .NET API is little more than a wrapper around the ObjectARX classes.  As such, it is almost at the same level as the C++ code.  The big difference is you have all the niceties of a managed language, as well as the large and powerful core .NET framework.  The tradeoff is that, as something that is hardly above the level of the C++ core, it is grungy to deal with.

This is completely an artifact of the API design, however.  The API could be expanded with objects that encapsulate and simplify a lot of this stuff.  And maybe in time, it will.

In the meantime, the best thing is to encapsulate the "messy" stuff inside of reusable components that you only write once.  Then just keep reusing those components in your code.  The code I posted at http://www.quux.biz illustrates this concept.

[Bryco]

I'm writing in net only because they are basically doing away with vba,
it's hard enough without decent help files and if it wasn't for the pioneers on this site I would have given up on it.
I'm kinda hooked now but still like grumbling about it.
As Nathan says, it does give better access to different things.
And an example of what Tim is saying may be something like; driving the vba car you give it some gas and it goes, .net needs to know how much gas and when to fire the cylinder

[It's Alive!]

Don’t forget, it’s fairly easy to party on the ActiveX API from .NET

[surveyor_randy]

Don’t forget, it’s fairly easy to party on the ActiveX API from .NET

Yeah, but I don't want to be the last guy at the party with the ugly woman, if you know what I mean!  Everyone else is switching to .NET.  I might as well just use this as an opportunity to learn C# while I'm at it.  So it seems that the best idea is to create "re-useable" components that I can just plug into my projects as I need them?  My only other gripe would be the inability to unload/reload a .DLL in AutoCAD while you are beta testing new code.

[It's Alive!]

Think of it this way. C++/CLI, C#, VB.NET etc. are platforms that you can design applications on. Autodesk has provided you with a .NET API that is essentially ObjectARX wrapped to be compatible with .NET. The good news is .NET is also compatible with ActiveX, and as you already know Autodesk has an ActiveX API.  So now you can party with the ugly one and the pretty one at the same time. w00t. 


PS. Thank you for considering C#.

[sinc]

In fact, with Civil-3D, you MUST use ActiveX, because there is no .NET API for C3D.

It often isn't pleasant mixing them, however.  It can get confusing keeping track of which is which, and knowing when and how to convert objects from one to the other.  Quite messy, in fact.  But it can be done.

[Nathan Taylor]

I'm writing in net only because they are basically doing away with vba,
it's hard enough without decent help files and if it wasn't for the pioneers on this site I would have given up on it.
I'm kinda hooked now but still like grumbling about it.
As Nathan says, it does give better access to different things.
And an example of what Tim is saying may be something like; driving the vba car you give it some gas and it goes, .net needs to know how much gas and when to fire the cylinder

I found your statement in the Autodesk groups about taking 4 hours to learn a C# Select Case interesting given my strong opinion on language choice most here would know about in regards to moving from VBA to .NET. Do you think it has been worthwhile learning C#? If so what are the reasons?

[Glenn R]

Nathan,

Well, my 'biggie', if you will (in the context of VBA to .NET), would be you have, at the very least, a readability of the following:

C/C++/Java and of course C#, in relation to your question and at the end of the day, VB is VB is VB...that's it.

Couple this with the fact that C# is a brand new (and often quoted as the premier MS .NET) language and it's a win win situation IMHO.
Not to mention the fact, that .NET 'features' have historically, to this date, been implemented in C# before VB...remember operator overloading. Admittedly, some of these are syntactic shortcuts, but the point is valid I think.

Cheers,
Glenn.

[sinc]

I've been enjoying C#.  I miss Objective-C categories, but other than that, I find it a pretty nice language to work with.

It might have been nice if Microsoft had taken another page from the Python book and gotten rid of the curly braces, but oh well.

[Kerry]

I find the C# curly braces help me breathe when reading code .. differentiating code blocks unambiguously.

... and my opinion of vb is known I think

[Bryco]

Nathan I found the jump to net (maybe this is because I didn't go straight to vb.net) to be a  way bigger jump than the jump from c# to vb, I haven't done any vb.net but I can read it fairly well as I see it as the same structure as my C# coding using vba words. The reason I did decide to go C# is that the help base here and other places seemed to be better in that direction. (And then there was the $5 I spent on a second hand book, there's just no going back from there.) As far as was it a good decision, I'm happy staying with c# but the differences mean less to me than others. I like the repetative End Sub, I end up typing something similar after the curly thangs anyway just to keep them straight. I like not having to worry about caps, but that's because I'm a bit sloppy, I can see why some coders like it more. I also like some of the ways you write C# better than the vb methods.
I feel I do know how to code in vba, which may mean I know about about the activeX api (I'm not sure what that is.), so when I have a problem in C# I would have thought I was having a net problem, not a problem in how to draw a line, perhaps someone can explain what the net.api and activex api are. (There is a bit of a row going on at the autodesk vba site about this)

[Nathan Taylor]

I haven't done any vb.net but I can read it fairly well as I see it as the same structure as my C# coding using vba words

I like that observation as it helps explain the difference between the API's. The similarity is where the .NET API is being used. If the the ActiveX API was being used then the VB.NET code would look very close to VBA code and the C# code would look like VBA code with C# words.

The reason I suggest people moving from VBA use VB.NET is because the difference between the languages is minor. So instead of spending 4 hours learning a new Select Case they can spend it learning how to use transactions.

There seems to be a need for a place that explains the different API technologies and their benefits/disadvantages and how they are used.

Unfortunately there are people using the ActiveX API with .NET languages. In some case they have a legitimate reason. In some cases they are coming in from the outside and are ignorant of the APIs availalble. In some cases they are moving from VBA, learn the new language and continue programming just as they did with VBA so don't really gain much.

One of the arguments the C#ers have used which I think has relevance is by using C# they can make a clean break from VBA. Unfortunately I have seen ex VBAers using C# to program AutoCAD in exactly the same way as they did in VBA which has really made me cringe.

The thing I like about the .NET API users is that at the end of the day no matter what our disagreements are about languages we can see past it and help each other.

[It's Alive!]

The thing I like about the .NET API users is that at the end of the day no matter what our disagreements are about languages we can see past it and help each other.

Well said

It doesn’t really matter what language one chooses to write with, but I would recommend people who choose VB
at least learn enough of the C style languages to be able to read the ObjectARX docs and C# users learn enough
about VB/A to read the ActiveX and VBA Developer's Guide. 

[MaksimS]

Just my 2 cents:

- Consider switching to VB.NET if you have extensive VB/VBA background
- In .NET, VB.NET and C# (including any other .NET language) have equal potentials
- Compared to ActiveX technology, .NET will get you a free ticket out of DLL hell
- .NET controls/components are way more "reusable" than ActiveX controls for that matter
- Kickstart in .NET will make you learn and understand OOP better than VB/VBA
- VS.NET is much more RAD-ready than any other IDE
- You may continue to use existing custom developed ActiveX contols in .NET, and translate them to .NET gradually
- When talking about managed ObjectARX, it will give you much more control over underlying Autodesk core than TLBs

Managed ObjectARX is simply a wrapper (with bonus) over native ObjectARX - once you understand how things work, you will notice that Autodesk's ActiveX controls introduce more abstraction and provide less control over ACAD's core. Remember, what you currently see through TLB sunglasses is _not_ how things work under the hood.

Regards,
Maksim Sestic

[Kerry]

<snip>   A good example would be offsetting a line. 
<snip>
How would you do this with .NET?  <snip>
 

Was this a rhetorical question ?

The Autodesk.AutoCAD.Geometry.OffsetCurve3d looks like a winner ...

I'll have some time tomorrow, if you don't yet have a solution. ... an extension method to add to a library shouldn't be  too difficult to knock together

[It's Alive!]

<snip>   A good example would be offsetting a line. 
<snip>
How would you do this with .NET?  <snip>
 

Was this a rhetorical question ?

The Autodesk.AutoCAD.Geometry.OffsetCurve3d looks like a winner ...

I'll have some time tomorrow, if you don't yet have a solution. ... an extension method to add to a library shouldn't be  too difficult to knock together

Also have a look at

Code: [Select]

DBObjectCollection Curve.GetOffsetCurves(double offsetDist);


[Kerry]

or
Autodesk.AutoCAD.DatabaseServices.Curve
public virtual DBObjectCollection GetOffsetCurves(double offsetDist);

[Kerry]

ahhhh. beaten by a smidgen

[It's Alive!]

I think this one has a bug in it when it comes to polylines, you have to do something like

Code: [Select]

   if (curve.GetType().Name == "Polyline")
      {
        distance = -distance;
      }

Could have been fixed though..?

[Kerry]

I'll let you know tomorrow Dan .. I recall reading something similar ..

added:
unless some enterprising bod tackles it first  

[It's Alive!]

I think this was one my first kludges with C#, there is an offset in here somewhere. 

Code: [Select]

using System;
using System.Collections.Generic;
using System.Text;
//
using Autodesk.AutoCAD.DatabaseServices;
using Autodesk.AutoCAD.Runtime;
using Autodesk.AutoCAD.Geometry;
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.EditorInput;
using AcadApp = Autodesk.AutoCAD.ApplicationServices.Application;
using Trans = Autodesk.AutoCAD.DatabaseServices;
namespace CrapDraw.Dualoffset
{
  public static class Dualoffset
  {
    [CommandMethod("dualoffset")]
    public static void dualoffset()
    {
      Editor ed = Application.DocumentManager.MdiActiveDocument.Editor;
      try
      {
        double offsetdist;
        offsetdist = (double)AcadApp.GetSystemVariable("OFFSETDIST");
        offsetdist = GetDouble("\nSpecify offset distance: ", offsetdist);
        if (offsetdist != 0)
        {
          Entity en = GetEntity("\nSelect object to offset: ");
          Offset(en, offsetdist / 2.0);
          Offset(en, -offsetdist / 2.0);
          Erase(en);
          AcadApp.SetSystemVariable("OFFSETDIST", offsetdist);
        }
      }
      catch
      {
        ed.WriteMessage("\n Error");
      }
    }
    private static ObjectIdCollection Offset(Entity ent, double distance)
    {
      ObjectIdCollection objectIdCollection = new ObjectIdCollection();
      Curve curve = ent as Curve;
      if (curve is Polyline)
      {
        distance = -distance;
      }
      DBObjectCollection dbObjectCollection = curve.GetOffsetCurves(distance);
      Database database = HostApplicationServices.WorkingDatabase;
      Trans.TransactionManager manager = database.TransactionManager;
      using (Transaction transaction = manager.StartTransaction())
      {
        BlockTable table = (BlockTable)manager.GetObject
              (database.BlockTableId, OpenMode.ForRead, false);

        BlockTableRecord record = (BlockTableRecord)manager.GetObject
               (table[BlockTableRecord.ModelSpace], OpenMode.ForWrite, false);

        foreach (DBObject obj in dbObjectCollection)
        {
          Entity entity = obj as Entity;
          objectIdCollection.Add(record.AppendEntity(entity));
          manager.AddNewlyCreatedDBObject(entity, true);
        }
        transaction.Commit();
      }
      return objectIdCollection;
    }
    private static Entity GetEntity(string prompt)
    {
      Editor ed = Application.DocumentManager.MdiActiveDocument.Editor;
      PromptEntityOptions entopts = new PromptEntityOptions(prompt);
      entopts.Message = prompt;
      entopts.AllowNone = false;
      PromptEntityResult ent = null;
      try
      {
        ent = ed.GetEntity(entopts);
      }
      catch
      {
        ed.WriteMessage("You did not select a valid entity");
      }
      if (ent.Status != PromptStatus.Error)
      {
        ObjectId entid = ent.ObjectId;
        Database database = HostApplicationServices.WorkingDatabase;
        try
        {
          Trans.TransactionManager manager = database.TransactionManager;
          using (Transaction transaction = manager.StartTransaction())
          {
            Entity entity = (Entity)manager.GetObject(entid, OpenMode.ForRead, true);//
            transaction.Commit();
            return entity;
          }
        }
        catch { }
      }
      return null;
    }
    private static void Erase(Entity ent)
    {
      Erase(ent.ObjectId);
    }
    private static void Erase(ObjectId id)
    {
      Trans.TransactionManager manager =
        HostApplicationServices.WorkingDatabase.TransactionManager;

      using (Transaction transaction = manager.StartTransaction())
      {
        ((Entity)manager.GetObject(id, OpenMode.ForWrite, true)).Erase();
        transaction.Commit();
      }
    }
    private static double GetDouble(string prompt, double def)
    {
      Editor ed = Application.DocumentManager.MdiActiveDocument.Editor;
      PromptDoubleOptions opt1 = new PromptDoubleOptions(prompt);
      opt1.AllowNone = false;
      opt1.AllowZero = false;
      opt1.DefaultValue = def;
      PromptDoubleResult doubleRes = ed.GetDouble(opt1);
      if (doubleRes.Status == PromptStatus.OK)
      {
        return (double)doubleRes.Value;
      }
      else
      {
        throw new System.NullReferenceException();
      }
    }
  }
}