Hi,
I'm finding that the ChildElemIter class when applied to a GroupedHole element does not return true for the ChildElemIter.IsValid method; however it does return true for a generic unnamed group (e.g. group together two independent, non-intersecting polygons). Is this expected? The docs don't mention anything about not being able to use this class for GroupedHoles.
My objective is to get the level ID of one of the shapes in the GroupedHole since the parent element just stores the Default level 0.
Thanks,
Martin
Hi Martin,
finally have some time to read forum posts ;-)
Martin Tyberg said:My objective is to get the level ID of one of the shapes in the GroupedHole since the parent element just stores the Default level 0.
Why you do not use (one from the most) standard solution in MicroStation CE API? ... IElementGraphicsProcessor?
When _AnnounceElemDisplayParams method is overridden, it reports level (and other attributes) of all elements. And in addition, the processor works with all MicroStation elements and does not care about their persistence format (whether they are cells, type 106 etc).
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Hi Jan,
Thank you for going through this thread. I had seen IElementGraphicsProcessor in my reading but didn't explore it further at the time. I see how it would provide me with the level of the first polygon in the grouped hole after a more detailed look. I will try it out. Thanks for the guidance on this.
Martin Tyberg said:I had seen IElementGraphicsProcessor in my reading but didn't explore it further at the time.
This is really one from core classes in MicroStation API and the standard way how to iterate elements' content regardless of type. Because you use C++, "geometry collectors" ecosystem is richer than in NET, sop to check more specialized classes like DropGeometry and DropGraphics can be useful too.
Martin Tyberg said:I see how it would provide me with the level of the first polygon in the grouped hole after a more detailed look.
It's easy when you are interested in geometry / attributes and not internal element itself.
It's a kind of "paradigm change" that causes troubles for experienced MicroStation developers, because we normally see cells, groped holes etc. as "cells with elements inside", whereas the processor provides information about geometry/topology/... and cannot be used (I think) to enumerate the elements itself..
Jan Šlegr said:This is really one from core classes in MicroStation API and the standard way how to iterate elements' content regardless of type. Because you use C++, "geometry collectors" ecosystem is richer than in NET, sop to check more specialized classes like DropGeometry and DropGraphics can be useful too.
Yah, I started playing with the C# API but I found it much easier to get done what I needed using the C++ API.
Jan Šlegr said:It's a kind of "paradigm change" that causes troubles for experienced MicroStation developers, because we normally see cells, groped holes etc. as "cells with elements inside", whereas the processor provides information about geometry/topology/... and cannot be used (I think) to enumerate the elements itself..
Yah, I tested it out and it gave me what I needed graphically for each of the cell's children.