scan GroupedHoleElement

Miro Cecho said:

I would like ask if it is any way in .Net environment to scan GroupedHoleElement

In addition to Jan's comments, you should note that a Grouped Hole is an anonymous cell.  That is, to find grouped holes you should search for anonymous cells.  Then, test the cell to determine if it is really a grouped hole.

Use CellElement.Drop() to get an ElementEnumerator of its components.

Jon Summers said:

In addition to Jan's comments, you should note that a Grouped Hole is an anonymous cell.

Well, it goes a bit beyond original topic, but in my opinion it's something that has not been important and should not be used in C++ API. So my comment is more about "API style and philosophy" than about how to implement working, despite of old-fashined, code.

My understanding of MicroStation C++ API and a move that begun long time ago when the new API was introduced in V8i SS3 (if I remember correctly) has been about move from data structures and data storage details (MSElementDescriptor, desing file element types, different ways how cells are used to represent cell, groupped elements, groupped holes, SmartSolids etc.) to higher level of abstractions (ElementHandlers).

From this reason I think any new code should not depend on element type evaluation and to check how specific object is stored in repository.

Regards,

  Jan

Jon Summers said:

In addition to Jan's comments, you should note that a Grouped Hole is an anonymous cell.

Well, it goes a bit beyond original topic, but in my opinion it's something that has not been important and should not be used in C++ API. So my comment is more about "API style and philosophy" than about how to implement working, despite of old-fashined, code.

My understanding of MicroStation C++ API and a move that begun long time ago when the new API was introduced in V8i SS3 (if I remember correctly) has been about move from data structures and data storage details (MSElementDescriptor, desing file element types, different ways how cells are used to represent cell, groupped elements, groupped holes, SmartSolids etc.) to higher level of abstractions (ElementHandlers).

From this reason I think any new code should not depend on element type evaluation and to check how specific object is stored in repository.

Regards,

  Jan

Jan Šlegr said:

higher level of abstraction

You're right: I found the GroupedHoleHandler Struct in MicroStationAPI help...

A grouped hole is a sub-type of cell.

A grouped hole cell must have a first child that is a closed curve with solid area type followed by at least one closed curve with hole area type. Displays fill using parity rules.

Jon Summers said:

A grouped hole is a sub-type of cell.

Yes, that's correct ... now and how it's implemented on top of DGN format.

(I know it's just my crazy assumption ;-) but in future, when storage format will change, code based on GroupedHoleHandler will remain the same (because there is zero dependency on data persistence implementation), but code based on assumption it's the cell and working in a way to "cast" handler to CellElement and working with elements individually become obsolete and will stop work.

Regards,

  Jan

Thanks for your recommendations, I should say that I work with Bentley Connect version (10.00.13.17) and we use C# addIns on .Net Framework 4.6.1. But in reality I’ m not much more successful. I can use Bentley.Interop.MicroStationDGN where is possible to scan this type of object.

It seems that we should stay on this approach.

Miro

Miro Cecho said:

I work with Bentley Connect version (10.00.13.17) and we use C# addIns on .Net Framework 4.6.1

This article shows how to enumerate elements in a DGN model using C#.

In the callback delegate mentioned there, you would do something like this to check if the current element is a grouped hole...

public StatusInt ElementProcessor(Element el, DgnModelRef modelRef)
{
  if (gh is GroupedHoleElement) 
  {
    ... do something with grouped hole
  }
  return StatusInt.Success;
}

Unfortunately C# doesn't have a GroupedHoleHandler that would make the above test more efficient.

Jon Summers said:

In the callback delegate mentioned there, you would do something like this to check if the current elements is a grouped hole...

As far as I remember, it has been discussed several times already to prefer simple enumeration.

In my opinion simple enumeration provides several different advantages:

• It provides flexibility to implement the elements filtering in a best way in project and usage context.
• When project and usage context will lead to delegation, to implement own code allows to optimize performance, whereas using ScanCriteria performance is defined by its implementation inside API.
• Alternative (and in some situations simpler) solutions can be used, e.g. anonymous function or hash-based decision table.

Jon Summers said:

Unfortunately C# doesn't have a GroupedHoleHandler that would make the above test more efficient.

Are you sure? I can see GroupedHoleElement class in the documentation.

With regards,

  Jan

Jan Šlegr said:

I can see GroupedHoleElement class in the documentation

I too can see GroupedHoleElement class in the documentation.  I can also see non-static member property IsGroupedHole.  What I don't see is a way to test whether any element, obtained from an enumeration or scan, is a grouped hole.  C++ makes that test simple with the GroupedHoleHandler interface.