ObjectId[] or ObjectIdCollection

[Dale.Bartlett]

Can someone explain the difference between ObjectId[] and ObjectIdCollection? In particular, I can create an ObjectId[] array but there appears to be no way to add items. Thanks Dale

[_gile]

Hi,

As you said ObjectId[] is a fixed size array, ObjectIdCollection a sizable collection, so, both types have different members (methods and properties).

You can create a new ObjectIdCollection passing an ObjectId[] as argument to an ObjectIdCollection constructor.

You can copy an ObjectIdCollection into an ObjectId[] using the ObjectIdCollection.CopyTo() method.

[Alfred.NESWADBA]

Hi,

a collection can hold items and have the option to that each item is paired with a key. The advantage is you can find a specific object quite fast and you can make sure that you don't have an item-key more than once in a collection. In case of ObjectIDCollection the ObjectID is used as item-object and as key.

The nativ array is a list of objects, one after the other, no check wether an object already exists in the list, no functionality to search for a specific object (you have to scan to the array and compare properties to find the item you are looking for), ....  And of course, you can ReDim an array to have more elements

Redim preserve X(100) ..... VB

Array.Resize(ref X, 100); ....C#

And to complete the description for Framework-arrays (instead of the original array) ==> collections and arrays get more and more functionality, so you have some methods now to push part of an array from one array-object to another, you have functionality now to search for specific objects within an array. So with every new release the difference between collection and array gets less and less and less.

And if you look for objects holding items of the same also look to list/sortedlist/hashtable/.... there are >>>so many blogs<<< with informations about what to use when, worth to read (now!).

- alfred -

[_gile]

"a collection can hold items and have the option to that each item is paired with a key. The advantage is you can find a specific object quite fast and you can make sure that you don't have an item-key more than once in a collection. In case of ObjectIDCollection the ObjectID is used as item-object and as key."

I do not agree. ObjectIdCollection implements IList, not IDictionary.

Both IList and IDictionary implements ICollection but they are two different specialized implementations.

From MSDN:

IDictionary and IList are more specialized interfaces that extend ICollection. An IDictionary implementation is a collection of key/value pairs, like the Hashtable class. An IList implementation is a collection of values and its members can be accessed by index, like the ArrayList class.

[Hallex]

         Using System.Reflection methods you can check the difference between them both like

            // say ids as ObjectIdCollection
            MessageBox.Show("Is type of DisposableWrapper: " + ids.GetType().IsSubclassOf(typeof(Autodesk.AutoCAD.Runtime.DisposableWrapper)).ToString());

            // say ods as array of ObjectId
            MessageBox.Show("Is type of Array: " + ods.GetType().IsSubclassOf(typeof(System.Array)).ToString());

[DiningPhilosopher]

---

@Alfred.NESWADBA wrote:

Hi,

a collection can hold items and have the option to that each item is paired with a key. The advantage is you can find a specific object quite fast and you can make sure that you don't have an item-key more than once in a collection. In case of ObjectIDCollection the ObjectID is used as item-object and as key.

---

Ummmm, sorry. That's not the case in .NET (it is in legacy VB6 but not in .NET).

A CLR collection doesn't use keys (a HashTable or Dictionary<TKey, TValue> does).

Additionally, a collection is not a logical set, and it doesn't restrict you from adding multiple elements that are equal (as defined by a user-provided EqualityComparer or the default comparer). A HashSet<T> is a logical set, which is like a collection except that it will not allow you to add mutiple items that are equal.

[DiningPhilosopher]

An array is not resizable, and doesn't allow you to add or remove elements.

A collection (see the ICollection interface) is resizable and permits addition/removal of items.

A managed equivalent of the ObjectIdCollection, would be System.Collections.Generic.List<ObjectId>, which is just a wrapper around an array, that manages its size and allows you to add/remove items.

[Alfred.NESWADBA]

Hi,

>> Additionally, a collection is not a logical set, and it doesn't restrict you

>> from adding multiple elements that are equal

Ever tried to add one (the same) ObjectID twice to a ObjectIsCollection-object?

>> An array is not resizable

And what does that:

   Dim X(1) as ObjectID

   Redim Preserve X(2)

???

- alfred -

[DiningPhilosopher]

---

@Alfred.NESWADBA wrote:

Hi,

>> Additionally, a collection is not a logical set, and it doesn't restrict you

>> from adding multiple elements that are equal

Ever tried to add one (the same) ObjectID twice to a ObjectIsCollection-object?

ObjectIdCollection is a managed wrapper around the native AcDbObjectIdArray, which is in-turn a wrapper around a C++ array. I've been using the native AcDbObjectIdArray since AutoCAD R13 was current (and it's managed wrapper since the first .NET API was released in AutoCAD 2006), and I can assure you that it will allow you to add the same ObjectId multiple times.

>> An array is not resizable

And what does that:

   Dim X(1) as ObjectID

   Redim Preserve X(2)

???

It creates a completely new array of the specified size, and then it copies the elements from the existing array to the new array, and replaces any references to the existing array with references to the new array. That's also why legacy VB programs that use redim preserve each time a new item is added an existing array, can be so pathically slow. 

That is not by-definition, 'resizing', but in the context of this topic, what I meant by 'resizeable' was that an array is not dynamically resizable with methods to add/remove elements without having to contend with the underlying details of what must happen when additional memory is needed. In reality, because a List<T> is just a wrapper around an array, it must do the same thing that redim preserve does, except that it is handled internally and hidden from the programmer, and it also doesn't have to be done each time another item is added (when additional capacity is required by the internal array, a new array is created whose size is double the size of the existing array, and the existing elements are copied to it). But, because capacity increases expontially, there is no need for to re-allocate memory for a new array and copy the data there, every time an element is added.

[antonio.leonardo]

Hi @Dale.Bartlett,

1) Starting by ObjectId class concept: The ObjectId class implements in your core features the IComparable:

The IComparable is interface contained at .NET Framework that allow developers to order or sort your collections, the IComparable contains a generic argument and one method to do implementation called CompareTo that will encapsulate the comparison rule implementation (by C# Autodesk API) that .NET Framework Api recognize this abstraction to outputs for developer ObjectId[] or List<ObjectId> with Sortable or Ordeble features.

2) The ObjectIdCollection is practically the same as ObjectId[] or List<ObjectId>, but with more approaches:

Because the ObjectIdCollection implements the IList interface, your collection will be aggregated with more advantages by functions like Add(ObjectId value), another comparison method as Contains(ObjectId value), CopyTo(ObjectId[] array, int index), get the index of an item parsed in argument called IndexOf(ObjectId value), removable itens by the instance of ObjectId or by index (the methods Remove(ObjectId value) or RemoveAt(int index)) and by a inheritance of DisposableWrapper class it's possible to use a Garbage Collector of your ObjectIdCollection instance, allows the developer controls recycle structs that alloc statical memory portions (as ObjecId array).

3) Conclusions: through ObjectIdCollection, the developer will enjoy far more collections functionality to support your business rule that needs to manipulate collections based on ObjectId.

Att,

Antonio Leonardo

[kerry_w_brown]

---

@antonio.leonardo wrote:

Hi @Dale.Bartlett,

1) Starting by ObjectId class concept: The ObjectId class implements in your core features  ......

I got to here then stopped.

The ObjectID is a struct, NOT a class ...

Regards,

[antonio.leonardo]

Thanks a lot, @kerry_w_brown.

@Dale.Bartlett, the answer with errata bellow:

1) Starting by ObjectId struct concept: The ObjectId struct implements in your core features the IComparable:

The IComparable is interface contained at .NET Framework that allow developers to order or sort your collections, the IComparable contains a generic argument and one method to do implementation called CompareTo that will encapsulate the comparison rule implementation (by C# Autodesk API) that .NET Framework Api recognize this abstraction to outputs for developer ObjectId[] or List<ObjectId> with Sortable or Ordeble features.

2) The ObjectIdCollection is practically the same as ObjectId[] or List<ObjectId>, but with more approaches:

Because the ObjectIdCollection implements the IList interface, your collection will be aggregated with more advantages by functions like Add(ObjectId value), another comparison method as Contains(ObjectId value), CopyTo(ObjectId[] array, int index), get the index of an item parsed in argument called IndexOf(ObjectId value), removable itens by the instance of ObjectId or by index (the methods Remove(ObjectId value) or RemoveAt(int index)) and by a inheritance of DisposableWrapper class it's possible to use a Garbage Collector of your ObjectIdCollection instance, allows the developer controls recycle structs that alloc statical memory portions (as ObjecId array).

3) Conclusions: through ObjectIdCollection, the developer will enjoy far more collections functionality to support your business rule that needs to manipulate collections based on ObjectId.

Att,

Antonio Leonardo

[antonio.leonardo]

1) Starting by ObjectId struct concept: The ObjectId struct implements in your core features the IComparable:

The IComparable is interface contained at .NET Framework that allow developers to order or sort your collections, the IComparable contains a generic argument and one method to do implementation called CompareTo that will encapsulate the comparison rule implementation (by C# Autodesk API) that .NET Framework Api recognize this abstraction to outputs for developer ObjectId[] or List<ObjectId> with Sortable or Ordeble features.

2) The ObjectIdCollection is practically the same as ObjectId[] or List<ObjectId>, but with more approaches:

Because the ObjectIdCollection implements the IList interface, your collection will be aggregated with more advantages by functions like Add(ObjectId value), another comparison method as Contains(ObjectId value), CopyTo(ObjectId[] array, int index), get the index of an item parsed in argument called IndexOf(ObjectId value), removable itens by the instance of ObjectId or by index (the methods Remove(ObjectId value) or RemoveAt(int index)) and by a inheritance of DisposableWrapper class it's possible to use a Garbage Collector of your ObjectIdCollection instance, allows the developer controls recycle structs that alloc statical memory portions (as ObjecId array).

3) Conclusions: through ObjectIdCollection, the developer will enjoy far more collections functionality to support your business rule that needs to manipulate collections based on ObjectId.

Att,

Antonio Leonardo