The basic problem with the filter list concept, is
that it doesn't offer the degree of flexibility which
increasingly sophisticated application requirements
need. For example, filtering on xdata or xrecord data
is the most common example of that.
In addition, complex filtering involving the use of
predicates and logical operators (), may
not be as effecient as directly examining each entity.
Whether it is, or not would depend on whether the
fitler list is compiled in some way (theoretically it
could be compiled to executable code, but I do not
think it is).
I also don't think that it would make sense to use the
notification-based filtering (SelectionAdded) for simple
filtering such as by entity type, so I wouldn't say that
the current filtering mechanism is going to disappear
any time soon.
The editor class is sealed because you cannot create
instances of it, you can only get them from the interop
framework (the Document class).
What good would inheriting from Editor do, given that
the base class cannot be instantated by a constructor?
AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
wrote in message news:email@example.com...
Thanks for the reply. I hadn't even thought about using the SelectionAdded event. A very good suggestion indeed. Also, you mentioned that filtering may become obsolete? Is this true? The reason I ask is because if it were true, Autodesk may want to mark the Editor class as "Inheritable". Right now it is marked as "NotInheritable" and that makes it a pain to extend is behavior. But it is still better than having to rely on COM libraries and the Interop that is generated.