Community
I do not see your dilemma has anything to do with being OOP or not OOP, it has something to do with how you associate your object of class with one or more AutoCAD entities, so that the object of your class holds information about the one or more entities. In this case, the logic would not be much different when you do it in VBA or in .NET. Just so you haven't done it in VBA: in VBA, you can create class HourGlass that represents your the visual elements in Acad (entities), and have a collection of HourGlass objects to represent selected HourGlass entities in drawing.
I'd imagine the HourGlass object would have a member field/property to hold ObjectId of the HourGlass (if it is a single Entity, such as Polyline/BlockReference). When you initilizing your collection of the class (say, List<HourGlass>), at some point, you need to SELECT the visual element in drawing (the entities shown as hour glass in drawing), either user selects them manually, or selects based on certain criteria, such as layer/color/linetype/entity type/block name...) and pass the selected entities' ObjectIds in, so for each ObjectId, you instantiate an HourGlass object and add it to the object collection.
If you need to use the HourGlass mutiple times during a drawing production process (e.g. a drawing could be worked on in multiple Acad session), you can consider to attach Xdata to the selected entities. So, the maunal selection only required to do once, and next time you need to get your HourGlass object/object collection, you can simply do SELECT by Xdata.
Again, this applies both VBA/.NET, nothing to do with OO spoecifically.
AutoCAD's managed runtime doesn't support custom objects
(what you call 'oop'), so there's no way to do what you want.
Native ObjectARX with C++ is the only way to do 'OOP'.
depending on your AutoCAD version, you can use a custom Overrule to do at least part of what you want.
There are a host of examples on Kean Walmsley's blog about different aspects of the technique, and I have also seen a webcast that (If I recall correctly) was Stephen Preston during Autodesk University last year.
Dave O. 
@Rudedog2 wrote:Couldn't you define a BLOCK and use it like a custom object?
Yes, but I don't think that's the kind of 'OOP' the OP was asking about.
For example, if you want to specialize a polyline or other built-in
entity, you have to derive a custom object from it (using native
ObjectARX).
Using blocks as 'pseudo-custom objects' offers the encapsulation
aspects of OOP, but not the inheritance aspects.
"I do not see your dilemma has anything to do with being OOP or not OOP, it has something to do with how you associate your object of class with one or more AutoCAD entities, so that the object of your class holds information about the one or more entities"
Actually, OOP is relevant to the OP's question, because
what he describes is a custom object that not only uses
encapsulation, but also demonstrates inheritance and
polymorphism.
His theoretical example cites a polyline that is specialized
to have a certain number of vertices and shape.
With a native C++ custom object that specializes the
Polyline object, you could implement exactly what the
OP describes, and any code would be ble to treat that
custom object as a polyline, and could for example,
obtain its length, araa, and so on.
Using a 'pseudo-custom object' (encapsulating one
or more entities in a block, or just attaching data to
another type of object) doesn't permit that (even
if that may not matter much in some cases).
That's also a reason why AutoCAD verticals often
use custom objects that derive from the Curve class.
Doing that allows any code that works with Curves
to treat those custom objects as Curves, and without
requiring the person that wrote the code to have any
specific knowledge about such objects or what they
represent exactly.
So, there is a difference between using blocks and/or
xdata/xrecords to create 'private', or 'pseudo-custom
objects' that only the programmer that created them
knows something about, and true custom objects that
can be dealt with more generically by any code.
In a perfect world, custom objects would offer the
best possible solution, but making it possible to
implement true custom objects in managed code is
****-near impossible.
And that's why we have Overrules. They give the
programmer a way to implement custom behavior
(albeit limited) for their own 'pseudo-custom objects'
without the need for/use of inheritance.
@junoj wrote:
So I guess there is not a whole lot of difference between .NET and VBA in that case. Just a language change but the logic is the same, and a true OOP.
No, there's a big difference between .NET and VBA.
VBA uses AutoCAD's ActiveX API, and .NET can use both ActiveX
and the AutoCAD .NET API. The latter is much more powerful and
complicated than the former, and can do things that VBA/ActiveX
can't do.
