I have moved from V8 MDL to Connect c#. I'm trying to locate the best method to obtain all the complex shape component elements from the element retrieved via Fence/Agenda.
I've tried
el.ExposeChildren(ExposeChildrenReason.Query);
ChildElementCollection ceColl = el.GetChildren();
foreach(Element elSub in ceColl) ...
But it doesn't work. I think my foreach is the problem.
Any help appreciated.
By design, most complex elements do not expose their child elements for any reason. Cells are an exception to this rule; complex shapes/strings are not.
Maybe explain what you are trying to accomplish by querying the child elements and we can identify a solution?
Thanks Paul, I'm trying to extract the element type and co-ordinate information for an analysis program. In the past (mdl V8) I always used the elemdesc and cycled through the sub elements. Is this still possible?
Yes, you can still bypass the handler API and iterate the components via the element descriptor. Please avoid using such approach to modify the components though.
Hi Paul,
Paul Connelly said:Maybe explain what you are trying to accomplish by querying the child elements and we can identify a solution?
When reading this discussion, a question / possible situation crossed my mind:
When there will be e.g. rule that complex chain or shape cannot contain B-spline (or arc or whatever other type). What is the best way how to do such analysis without using element descriptor (that probably will gone in future)?
Expose and iterate childrens and to compare element types was tradition and simple way. Is recommended now to query geometry and to analyse it? But geometry is not exactly element type (but I have not thing about it in detail ;-).
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Jan Ĺ legr said:Is recommended now to query geometry and to analyse it?
If you want to determine whether or not a complex shape contains a b-spline, yes - iterate its geometry looking for b-splines. The fact that a complex chain happens to define its geometry in terms of component elements is an internal detail relevant almost exclusively to the handler.
Jan Ĺ legr said:But geometry is not exactly element type
This has become more and more true as MicroStation has evolved, to the extent that if you are checking element type codes today, your code probably has a bug.
For example, what is the 'type' of a Table, Label, or Parametric Cell element? The answer for all of them and many others is EXTENDED_ELM, which isn't even in the public SDK and conveys no useful information. You can't do anything useful with such elements without going through the handler.
Thanks,
I appreciate your helpful advice Paul.
My original intention was to take advantage of higher level read access. Hence the question. I would prefer not to cycle through the lower level calls as you point out they areorw likely to change.
Here is how it used to look.
if (!mdlElmdscr_read(&dscrP,fPos,dgnMRP,FALSE,NULL)) LeaveWithTextMessage("Error in Complex Shape",-1); for (index=0,ptr=dscrP->h.firstElem; ptr != NULL && index < MAX_VERT; ptr = ptr->h.next) { erno=1; switch(ptr->el.ehdr.type) { case LINE_ELM : case LINE_STRING_ELM : if(index!=0) index--; if(mdlLinear_extract(&verticesD[index],&nopts,&ptr->el, dgnMRP)!=SUCCESS) LeaveWithTextMessage("Error Reading Linear Element",-1); index=index+nopts; break; case ARC_ELM :
It looks like you care about the geometry, not the element type, but are using the element type to figure out what type of geometry you have.
If so you might consider using ElementGraphicsOutput::Process(), passing in your element along with an implementation of IElementGraphicsProcessor. This will allow you to process geometry from any type of element (including extended elements and other types not included in the public SDK).
Thanks Jan,
I'm belatedly moving from the MDL world so I'm not qualified to comment meaningfully on the advantages and disadvantages of the directions of change. But in the past it has always been the case that new innovations always allowed us to do all the functional operations we could in the past, plus more. I would be surprised if this is not the case. My problem is that I have to find my way around to get where I need to go in a different programming context.
So I'm thankful for the prompt help and input I received tonight (here in Australia)
David
That sounds like it might be a really good solution. I'll try it out. Tomorrow!
Thanks for persisting with me Paul
David Hall said:My problem is that I have to find my way around to get where I need to go in a different programming context
Well, we all must do that! The leap from MDL to the CONNECT C++ MicroStationAPI is huge. Many MDL functions have been replaced with classes having better, and more coherent, functionality. Sometimes what were C-style structs in MDL have metamorphosed into classes: for example, DPoint3d. There remain some MDL functions lurking, which come as a surprise when encountered.
DPoint3d
CONNECT has a genuine C# API, documented confusingly in several .chm files. C# is no longer, for the most part, hampered by the need to call VBA via an InterOp: it's a wrapper around the C++ classes.
.chm
David Hall said:My problem is that I have to find my way around
That's true for all of us, except the VBA scribblers. The VBA API is almost, apart from stretching to 64-bits, unchanged.
Regards, Jon Summers LA Solutions