Connect Update 17 C++ Retrieving the children of a groupedhole element

Martin Tyberg said:

the ChildElemIter class when applied to a GroupedHole element does not return true for the ChildElemIter.IsValid method

A GroupedHole element is an anonymous cell.  See the comments here: The complex chain handlers were changed in MicroStation CONNECT Edition compared to their V8-generation predecessors. They no longer expose their child elements to callers. Also, ChildElemIter no longer provides a way to navigate the children of complex elements such as a cell.

Despite the above, this code works for me...

bool LabelHelper::ContainsNestedAnnotation	(ElementHandleCR cell,
                                                WCharCP           innerCellName)
{
  for (ChildElemIter child (cell); child.IsValid (); child = child.ToNext ())
  {
    if (MicroStation::IsNormalCell (child))
    {
      NormalCellHeaderHandler*  innerCell = dynamic_cast<NormalCellHeaderHandler*>(child.GetDisplayHandler ());
      return MatchCellName (innerCell, child, innerCellName);
    }

    if (MicroStation::IsComplex (child))
    {
      if (ContainsNestedAnnotation (child, innerCellName))
        return true;
    }
  }
  return false;
}

Martin Tyberg said:

the ChildElemIter class when applied to a GroupedHole element does not return true for the ChildElemIter.IsValid method

A GroupedHole element is an anonymous cell.  See the comments here: The complex chain handlers were changed in MicroStation CONNECT Edition compared to their V8-generation predecessors. They no longer expose their child elements to callers. Also, ChildElemIter no longer provides a way to navigate the children of complex elements such as a cell.

Despite the above, this code works for me...

bool LabelHelper::ContainsNestedAnnotation	(ElementHandleCR cell,
                                                WCharCP           innerCellName)
{
  for (ChildElemIter child (cell); child.IsValid (); child = child.ToNext ())
  {
    if (MicroStation::IsNormalCell (child))
    {
      NormalCellHeaderHandler*  innerCell = dynamic_cast<NormalCellHeaderHandler*>(child.GetDisplayHandler ());
      return MatchCellName (innerCell, child, innerCellName);
    }

    if (MicroStation::IsComplex (child))
    {
      if (ContainsNestedAnnotation (child, innerCellName))
        return true;
    }
  }
  return false;
}

Hi Jon,

Thank you for your answer. I had seen your article when I was searching for info on this issue but I couldn't find any reference to this in the official Microstation Docs. Do you know where I could find this?

Your code works for me too on anonymous cells as long as they aren't grouped hole anonymous cells - not sure why. 

In any event, do you know of a proper way to get the level of a grouped hole element since this can only be retrieved by its children (the parent cell's level is always 0 - if I change the grouped hole element's level in the Microstation UI to a different level, the cell's level remains 0 and the children elements' level only changes)?

Thanks,

Martin

Martin Tyberg said:

Do you know of a proper way to get the level of a grouped hole element since this can only be retrieved by its children (the parent cell's level is always 0

A cell header element is not a graphical element and has neither symbology nor level.

The components of a cell are usually graphical, and therefore have both symbology and a level.  However, cells may be nested, so when enumerating the contents of a cell you must detect nested cells and enumerate those.  Usually a recursive algorithm works.

Each graphic component of a cell may have its own symbology and level.  A cell that contains 10 DGN graphic elements could have ten different colours on ten different levels.

Martin Tyberg said:

I couldn't find any reference to this in the official Microstation Docs. Do you know where I could find this?

From the 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 .

Martin Tyberg said:

Your code works for me too on anonymous cells as long as they aren't grouped hole anonymous cells

AFAIK a grouped hole is no more than an anonymous cell.  It has topology, defined by its component shapes.  There's nothing in a grouped hole that says "I am a grouped hole".  The MicroStation tool that creates a grouped hole is responsible for checking that topology.

It's not clear why your code fails.  Please post a DGN example of your grouped hole.

Jon Summers said:

A cell header element is not a graphical element and has neither symbology nor level.

The components of a cell are usually graphical, and therefore have both symbology and a level.  However, cells may be nested, so when enumerating the contents of a cell you must detect nested cells and enumerate those.  Usually a recursive algorithm works.

Each graphic component of a cell may have its own symbology and level.  A cell that contains 10 DGN graphic elements could have ten different colours on ten different levels.

Ok, I thought maybe Microstation's algorithm for knowing to categorize an anonymous cell as a grouped hole (when you hover over a grouped hole in the view with the mouse, it tells you it's a grouped hole and on which level it's on which seems to always be the level the last hole added is on) was partly related to checking that all holes and parent polygon are on the same level but I see now that you can create a grouped hole with each hole on a different level. So is there a proper way to get the level of the first child (parent polygon)? For now, I've resorted to getting a MS element descriptor and using the old mdlElement_getProperties function.

Jon Summers said:

From the 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

I meant I couldn't find in the docs that ChildElemIter isn't supposed to work anymore on complex elements like cells. 

Jon Summers said:

It's not clear why your code fails.  Please post a DGN example of your grouped hole.

Please find attached a dgn file with a single grouped hole in which ChildElemIter::IsValid() fails.

Test1.dgn

Thanks,

Martin

Martin Tyberg said:

Test1.dgn

OK: you have a valid grouped hole element.  I used MicroStation's hatch tool to achieve this...

Martin Tyberg said:

I meant I couldn't find in the docs that ChildElemIter isn't supposed to work anymore on complex elements like cells

Well, it's not formally documented.  I think that comment arose from a conversation on this Forum several years ago with one of the Bentley Developers (probably Brien Bastings).

Perhaps Robert Hook can comment?

Jon Summers said:

OK: you have a valid grouped hole element.  I used MicroStation's hatch tool to achieve this...

Thanks for checking.

Jon Summers said:

Well, it's not formatlly documented.  I think that comment arose from a conversation on this Forum several years ago with one of the Bentley Developers (probably Brien Bastings).

Ah ok, thanks.

Martin