.NET
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

.NET and Autocad versions...

12 REPLIES 12
Reply
Message 1 of 13
Anonymous
937 Views, 12 Replies

.NET and Autocad versions...

In wich versions of AutoCad can I write C# programs for?
I'm also intrested in ADT versions...
12 REPLIES 12
Message 2 of 13
Anonymous
in reply to: Anonymous

Both AutoCAD 2005 and AutoCAD 2006 expose a .NET API; the coverage is much
more extensive in AutoCAD 2006.

Using C# with earlier versions is possible with COM Interop or even
P/Invoke.

Dan

"Anders Pettersson" wrote in message
news:4868401@discussion.autodesk.com...
In wich versions of AutoCad can I write C# programs for?
I'm also intrested in ADT versions...
Message 3 of 13
Anonymous
in reply to: Anonymous

AutoCAD 2005 had a partial .NET implementation (say 60% of ObjectARX coverage) and AutoCAD 2006 has a virtually complete .NET implementation (say 95%... the main part missing is custom object creation).

ADT 2006 is the first version of ADT with .NET support with a partial implementation (say 40%)... more to come next year.
Message 4 of 13
Anonymous
in reply to: Anonymous

This is a bit misleading.

If you quantify coverage in terms of the number of native
ObjectARX classes wrapped, it's not even close.

If you consider that many wrappers do not expose the
complete functionality of the underlying native class,
your even farther away.

95% is essentially a fairy tale. Not even taking into
account custom object creation, I'd guess that in terms
of functionality, it is about 50%. Consider that AdUi and
AcUi are not exposed at all via managed wrappers, with
the exception of Palettes.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:4869735@discussion.autodesk.com...
AutoCAD 2005 had a partial .NET implementation (say 60% of ObjectARX coverage) and AutoCAD 2006 has a virtually complete
.NET implementation (say 95%... the main part missing is custom object creation).

ADT 2006 is the first version of ADT with .NET support with a partial implementation (say 40%)... more to come next
year.
Message 5 of 13
Anonymous
in reply to: Anonymous

I don't want to get into the percentage discussion. 3 things that I'd like
to point out:

1. I don't think we ever want to wrap the AcUi, AdUi functionality. Winforms
do a much better job.
2. Please don't hesitate to point out when you run into holes. We will try
to fix them.
3. I'd like to think that the .NET API does a better job at usability than
the C++ API. Compare acedSSGet to the various GetSelection methods. Or the
ease of creating a palette using the .NET API vs. using AcUi/AdUi.

Albert

"Tony Tanzillo" wrote in message
news:4870748@discussion.autodesk.com...
This is a bit misleading.

If you quantify coverage in terms of the number of native
ObjectARX classes wrapped, it's not even close.

If you consider that many wrappers do not expose the
complete functionality of the underlying native class,
your even farther away.

95% is essentially a fairy tale. Not even taking into
account custom object creation, I'd guess that in terms
of functionality, it is about 50%. Consider that AdUi and
AcUi are not exposed at all via managed wrappers, with
the exception of Palettes.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:4869735@discussion.autodesk.com...
AutoCAD 2005 had a partial .NET implementation (say 60% of ObjectARX
coverage) and AutoCAD 2006 has a virtually complete
.NET implementation (say 95%... the main part missing is custom object
creation).

ADT 2006 is the first version of ADT with .NET support with a partial
implementation (say 40%)... more to come next
year.
Message 6 of 13
Anonymous
in reply to: Anonymous

Well, I don't agree completely with regards to AcUi/AdUi.

That isn't to suggest that you should *directly* expose things
like CAcUiDialog, but rather that AutoCAD-specific functionality
provided by that and other AcUi/AdUi classes most definitely
should be exposed in the form of WinForms-based classes.

I also feel that all of the property inspector functionality and its
custom controls (most of which are heavily dependent on COM)
should be exposed as managed wrappers if for no other reason,
consistency's sake.

Regarding holes, see my other post 🙂

And please keep in mind that I've not really explored or used
the Managed wrappers very much, and I'm still seeing lots of
missed opportunities. I hope it's not the tip of an iceberg.


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message news:4871040@discussion.autodesk.com...
I don't want to get into the percentage discussion. 3 things that I'd like
to point out:

1. I don't think we ever want to wrap the AcUi, AdUi functionality. Winforms
do a much better job.
2. Please don't hesitate to point out when you run into holes. We will try
to fix them.
3. I'd like to think that the .NET API does a better job at usability than
the C++ API. Compare acedSSGet to the various GetSelection methods. Or the
ease of creating a palette using the .NET API vs. using AcUi/AdUi.

Albert

"Tony Tanzillo" wrote in message
news:4870748@discussion.autodesk.com...
This is a bit misleading.

If you quantify coverage in terms of the number of native
ObjectARX classes wrapped, it's not even close.

If you consider that many wrappers do not expose the
complete functionality of the underlying native class,
your even farther away.

95% is essentially a fairy tale. Not even taking into
account custom object creation, I'd guess that in terms
of functionality, it is about 50%. Consider that AdUi and
AcUi are not exposed at all via managed wrappers, with
the exception of Palettes.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:4869735@discussion.autodesk.com...
AutoCAD 2005 had a partial .NET implementation (say 60% of ObjectARX
coverage) and AutoCAD 2006 has a virtually complete
.NET implementation (say 95%... the main part missing is custom object
creation).

ADT 2006 is the first version of ADT with .NET support with a partial
implementation (say 40%)... more to come next
year.
Message 7 of 13
Anonymous
in reply to: Anonymous

I'm really curious what you have in mind with regards to AdUi/AcUi. What do
they provide that winforms doesn't? Note that we did provide access to
palettes because that is indeed AutoCAD specific. But what else?

Yes, property palette is an interesting animal. Of course, Winforms provides
a more extensible property browser called the PropertyGrid. I see an need
for bridge between Property Palette and the Property Grid but the Property
Palette is a primary concern for people who create custom objects.

Very good. Keep exploring and post your concerns here. I know there are
opportunities and we are not complete by any means but we are making
progress.

Albert

"Tony Tanzillo" wrote in message
news:4871092@discussion.autodesk.com...
Well, I don't agree completely with regards to AcUi/AdUi.

That isn't to suggest that you should *directly* expose things
like CAcUiDialog, but rather that AutoCAD-specific functionality
provided by that and other AcUi/AdUi classes most definitely
should be exposed in the form of WinForms-based classes.

I also feel that all of the property inspector functionality and its
custom controls (most of which are heavily dependent on COM)
should be exposed as managed wrappers if for no other reason,
consistency's sake.

Regarding holes, see my other post 🙂

And please keep in mind that I've not really explored or used
the Managed wrappers very much, and I'm still seeing lots of
missed opportunities. I hope it's not the tip of an iceberg.


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message
news:4871040@discussion.autodesk.com...
I don't want to get into the percentage discussion. 3 things that I'd like
to point out:

1. I don't think we ever want to wrap the AcUi, AdUi functionality. Winforms
do a much better job.
2. Please don't hesitate to point out when you run into holes. We will try
to fix them.
3. I'd like to think that the .NET API does a better job at usability than
the C++ API. Compare acedSSGet to the various GetSelection methods. Or the
ease of creating a palette using the .NET API vs. using AcUi/AdUi.

Albert

"Tony Tanzillo" wrote in message
news:4870748@discussion.autodesk.com...
This is a bit misleading.

If you quantify coverage in terms of the number of native
ObjectARX classes wrapped, it's not even close.

If you consider that many wrappers do not expose the
complete functionality of the underlying native class,
your even farther away.

95% is essentially a fairy tale. Not even taking into
account custom object creation, I'd guess that in terms
of functionality, it is about 50%. Consider that AdUi and
AcUi are not exposed at all via managed wrappers, with
the exception of Palettes.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:4869735@discussion.autodesk.com...
AutoCAD 2005 had a partial .NET implementation (say 60% of ObjectARX
coverage) and AutoCAD 2006 has a virtually complete
.NET implementation (say 95%... the main part missing is custom object
creation).

ADT 2006 is the first version of ADT with .NET support with a partial
implementation (say 40%)... more to come next
year.
Message 8 of 13
tangferry
in reply to: Anonymous

But you can not use conditinal selectionset.For example,I cannot select both circles or lines with Getselection.

3. I'd like to think that the .NET API does a better job at usability than
the C++ API. Compare acedSSGet to the various GetSelection methods. Or the
ease of creating a palette using the .NET API vs. using AcUi/AdUi.

Albert
Message 9 of 13
Anonymous
in reply to: Anonymous

Yes. This however is simply a bug in the code. We wanted enable conditional
filtering in its full glory. On the other hand the .NET GetSelection method
returns all the details of how the objects got selected. You simply can't do
that using the COM API and you have to go through some arcane resbuf parsing
to get this data using C++. You can't implement commands like trim or
stretch without knowing what part of the object was selected.

Albert

wrote in message news:4871213@discussion.autodesk.com...
But you can not use conditinal selectionset.For example,I cannot select both
circles or lines with Getselection.

3. I'd like to think that the .NET API does a better job at usability than
the C++ API. Compare acedSSGet to the various GetSelection methods. Or the
ease of creating a palette using the .NET API vs. using AcUi/AdUi.

Albert
Message 10 of 13
Anonymous
in reply to: Anonymous

wrote

>> But you can not use conditinal selectionset.For example,
>> I cannot select both circles or lines with Getselection.

Yes you can.

new TypedValue(0, "CIRCLE,LINE');

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

3. I'd like to think that the .NET API does a better job at usability than
the C++ API. Compare acedSSGet to the various GetSelection methods. Or the
ease of creating a palette using the .NET API vs. using AcUi/AdUi.

Albert
Message 11 of 13
Anonymous
in reply to: Anonymous

BTW, you might want to know that it isn't necessary to
deal with the result of calling the ActiveX Select() method,
as your (disassembled) code below does.

Any call to acedSSGet() which produces a valid selection set,
causes that selection set becoming the Previous selection set.

Hence, all you have to do is call the AcadSelectionSet.Select()
method and if it succeeds, you can get the resulting selection
set via Editor.SelectPrevious(), and you then have a managed
SelectionSet to work with. So, don't bother with returning an
ObjectIdCollection. Instead, declare your function's retun type
as PromptSelectionResult, and call Editor.SelectPrevious(), and
just return its result.

public static ObjectIdCollection SelectAll(TypedValue[] filter)
{
int num1 = filter.Length;
short[] numArray1 = new short[num1];
object[] objArray1 = new object[num1];
for (int num2 = 0; num2 < num1; num2++)
{
numArray1[num2] = filter[num2].TypeCode;
objArray1[num2] = filter[num2].Value;
}
AcadDocument document1 = (AcadDocument) Application.DocumentManager.MdiActiveDocument.AcadDocument;
AcadSelectionSet set1 = document1.get_SelectionSets().Add("temp");
set1.Select(5, Type.Missing, Type.Missing, numArray1, objArray1);
int num4 = set1.get_Count();
Tools.Editor.WriteMessage(num4.ToString() + " objects have been selected.");
ObjectIdCollection collection1 = new ObjectIdCollection();
for (int num3 = 0; num3 < set1.get_Count(); num3++)
{
collection1.Add(DBObject.FromAcadObject(set1.Item(num3)));
}
set1.Delete();
return collection1;
}

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:4871213@discussion.autodesk.com...
But you can not use conditinal selectionset.For example,I cannot select both circles or lines with Getselection.

3. I'd like to think that the .NET API does a better job at usability than
the C++ API. Compare acedSSGet to the various GetSelection methods. Or the
ease of creating a palette using the .NET API vs. using AcUi/AdUi.

Albert
Message 12 of 13
Anonymous
in reply to: Anonymous

informative thread Gentlemen, Thanks.
"Tony Tanzillo" wrote in message
news:4871326@discussion.autodesk.com...
BTW, you might want to know that it isn't necessary to
deal with the result of calling the ActiveX Select() method,
as your (disassembled) code below does.

Any call to acedSSGet() which produces a valid selection set,
causes that selection set becoming the Previous selection set.

Hence, all you have to do is call the AcadSelectionSet.Select()
method and if it succeeds, you can get the resulting selection
set via Editor.SelectPrevious(), and you then have a managed
SelectionSet to work with. So, don't bother with returning an
ObjectIdCollection. Instead, declare your function's retun type
as PromptSelectionResult, and call Editor.SelectPrevious(), and
just return its result.

public static ObjectIdCollection SelectAll(TypedValue[] filter)
{
int num1 = filter.Length;
short[] numArray1 = new short[num1];
object[] objArray1 = new object[num1];
for (int num2 = 0; num2 < num1; num2++)
{
numArray1[num2] = filter[num2].TypeCode;
objArray1[num2] = filter[num2].Value;
}
AcadDocument document1 = (AcadDocument)
Application.DocumentManager.MdiActiveDocument.AcadDocument;
AcadSelectionSet set1 = document1.get_SelectionSets().Add("temp");
set1.Select(5, Type.Missing, Type.Missing, numArray1, objArray1);
int num4 = set1.get_Count();
Tools.Editor.WriteMessage(num4.ToString() + " objects have been
selected.");
ObjectIdCollection collection1 = new ObjectIdCollection();
for (int num3 = 0; num3 < set1.get_Count(); num3++)
{
collection1.Add(DBObject.FromAcadObject(set1.Item(num3)));
}
set1.Delete();
return collection1;
}

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:4871213@discussion.autodesk.com...
But you can not use conditinal selectionset.For example,I cannot select both
circles or lines with Getselection.

3. I'd like to think that the .NET API does a better job at usability than
the C++ API. Compare acedSSGet to the various GetSelection methods. Or the
ease of creating a palette using the .NET API vs. using AcUi/AdUi.

Albert
Message 13 of 13
aslam
in reply to: Anonymous

Hi all,
I need to know how can i access property palette of Autocad and show a property of given Autocad Object through propgramming.
Thanks..

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report

”Boost