.NET and Autocad versions...

.NET and Autocad versions...

Anonymous
Not applicable
1,512 Views
12 Replies
Message 1 of 13

.NET and Autocad versions...

Anonymous
Not applicable
In wich versions of AutoCad can I write C# programs for?
I'm also intrested in ADT versions...
0 Likes
1,513 Views
12 Replies
Replies (12)
Message 2 of 13

Anonymous
Not applicable
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...
0 Likes
Message 3 of 13

Anonymous
Not applicable
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.
0 Likes
Message 4 of 13

Anonymous
Not applicable
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.
0 Likes
Message 5 of 13

Anonymous
Not applicable
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.
0 Likes
Message 6 of 13

Anonymous
Not applicable
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.
0 Likes
Message 7 of 13

Anonymous
Not applicable
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.
0 Likes
Message 8 of 13

Anonymous
Not applicable
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
0 Likes
Message 9 of 13

Anonymous
Not applicable
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
0 Likes
Message 10 of 13

Anonymous
Not applicable
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
0 Likes
Message 11 of 13

Anonymous
Not applicable
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
0 Likes
Message 12 of 13

Anonymous
Not applicable
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
0 Likes
Message 13 of 13

Anonymous
Not applicable
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..
0 Likes