[Microstation V8i MDL C++ API] Creating complex shape causing my subchildren to connect even though the element is closed.

Hello!

I´m trying to create a complex element consisting of multiple subelements :

  1. Line
  2. Complex chain consisting of N segments
  3. Line
  4. Complex chain consisting of N segments

For that I´m using C++ MDL API.  First I create complex header via mdlComplexChain_createHeader. Then I create my subelements. Lines are created within single mdlLine call, while Complex chains are in loops with multiple mdlLine calls and then appending them to the mother header(The complex chain). After I create them, i append them to the owner with mdlElmdscr_appendDscr() . However, even though my creation is closed element (all lines are connected), microstation keeps adding a line between my two single lines, like the shape wasnt closed or something. Im also attaching a picture describing my problem. The same behavior happens even if i dont add the complex chains...

Thanks for any tips.

Lubo

Parents
  • First I create complex header via mdlComplexChain_createHeader. Then I create my subelements. Lines are created within single mdlLine call, while Complex chains are in loops with multiple mdlLine calls and then appending them to the mother header(The complex chain). After I create them, i append them to the owner with mdlElmdscr_appendDscr()

    It's faster to post a code sample than to describe it.  Also, a code sample removes any ambiguity in our interpretation of what you're doing.

    MicroStation keeps adding a line between my two single lines

    The direction of lines is important.  In the closed shape you are creating, all components must be clockwise or counter-clockwise.

    I use MSVC

    Here's a table of Visual Studio and MicroStation SDK versions.

     
    Regards, Jon Summers
    LA Solutions

  • I tried to play around also with the directions of my lines, sometimes the "connection line"(the problematic one) changes direction too ( changes the vertices that its connecting), but I never got to get rid of it. I also tried to specify in mdlComplexChain_createHeader that I wanted to create complex chain instead of complex shape(in hope of this line disappearing), but didnt work as well. The problem is also that I cant access this problematic line from code, so cant hide it manually after creating my element. 

  • One more comment or, better to say, question: Why you want to create complex shape with nested another complex strings (complex chains)?

    Even when MicroStation itself uses nested complex cells sometimes (e.g. TriForma shapes, or SmarSolids) and it's possible to create such structures (because it's allowed by DGN V8 format specification), they are in fact "from the past heritage", when it was the simplest workaround of complex requirements.

    When you will study a presentation from migration workshop (to CE platform):

    In most cases:
    - We found Complex elements to be WRONG during i-model platform optimization
    - Less need to use MSElement and MSElementDescr types (applause)
    - MSElement should only be used for Handlers Only
    
    Nesting = bad

    You can see that in CONNECT Edition, new elements (e.g. parametric modeling) are implemented using relationships, not nesting.

    For normal elements, one level nesting (flat structures inside shapes, chains and cells) is recommended, because it does not require recursion, which is treated as a threat in a code and should be avoided when not really necessary.

    With regards,

      Jan

  • A type 12 CMPLX_STRING_ELM is intended to represent a single open path, a type 14 CMPLX_SHAPE_ELM a single closed loop.

    The components of a complex chain or shape are expected to be connected head to tail, any gaps are filled with a linear stroke to ensure that the element displays as a path or loop..

    It is not valid to add a complex chain or shape as a child of another complex chain or shape, the only valid components are simple open elements, LINE_ELM, LINE_STRING_ELM, CURVE_ELM, ARC_ELM, and open BSPLINE_CURVE_ELM.

    Maybe you want a type 2 CELL_HEADER_ELM for your outermost complex header, or maybe you just want to add the components of the nested chains directly w/o creating nested chains...maybe you just want a type 6 SHAPE_ELM? 

    HTH

    -B



  • I have it like this because i wanted a way to differentiate between parts of my element in VBA.  

    Then I want to apply my VBA macro, where I can simply determine which line am I working with by identifying if Im iterating inside a complex chain or just a simple line. I encapsulated these all lines and chains into another complex shape because in my macro I want to use getIntersectionPoints method from complex shape.

  • It is not valid to add a complex chain or shape as a child of another complex chain or shape
    I have it like this because i wanted a way to differentiate between parts of my element in VBA

     is a member of the core development team.  If he says: "Don't do it that way", then don't do it that way!

    But, rather than debating the merits of nested elements, raise the discussion to a higher level.  Put your problem to us and ask for tips.  For example: "How can I identify the origin or provenance of the components of a complex shape?"

    One way, for example, would be to attach some sort of data tag to those elements.  With MicroStation, you're spoiled for choice — or would be if you didn't want to interrogate the complex chain using VBA. Possibilities include...

    • User Attribute Data
    • DataBlock
    • XDatum

    With CONNECT you might additionally consider Item Types. There's a VBA API for all of those.

     
    Regards, Jon Summers
    LA Solutions

  • Hi Lubo,

    thanks for the explanation.

    i wanted a way to differentiate between parts of my element in VBA.

    A context is not provided, so it's not quite clear why you need to differentiate between parts (what they represent), but to use element types is not good idea ... and as Brien confirmed, to create nested complex chain / shape is not possible.

    The problem with element types is that it can be changed when specific tools are used (e.g. trim converts shape to line string). Depending on context it can cause serious troubles or can be fined (because cannot happened ;-).

    I think there are two solutions available:

    • To use a cell as a container. Cell is the only element that allows nested content, so you can you your approach, but it is not editable, which can be a problem, when it's expected e.g. Modify element tool will be used.
    • As Jon wrote, to tag element by custom data. In my opinion it's more elegant solution, in parallel with general recommendations and best practices. Data, that can be accessed both from native and VBA code is limited, but I think User Attribute Data is a good choice (XData were designed to be used with DWG, so it's not recommended to use them in DGN). If there is a vision of using the code for a long time, I would recommend EC data, but it's quite complicated in V8i (but possible).

    With regards,

      Jan

  • Thank you guys for your tips. I will try to come up with a suitable solution. 

    To use a cell as a container. Cell is the only element that allows nested content, so you can you your approach, but it is not editable, which can be a problem, when it's expected e.g. Modify element tool will be used.

    Could you please tell me more about saying it will be not editable? Like for example, if I decide to change linestyle for some of the lines of my element?  

  • Could you please tell me more about saying it will be not editable?

    Editable by a user, you can try it manually:

    • It's possible to modify complex chain or shape geometry using modify tool or selection arrow.
    • It's not possible do the same with cell content, because it's encapsulated by a cell. I guess the only content that can be edited by a user directly are texts and text nodes.
    Like for example, if I decide to change linestyle for some of the lines of my element?  

    You did not mentioned this requirement before and it's another thing that disqualify complex chain / shape to be used, because by definition, all content has to have the same symbology.

    Cell content can be any (every element can have different symbology in graphic cells) and can be modified when necessary, even when it's typically not good idea when user want to change some part of the cell.

    Regards,

      Jan

  • At first I didnt think that could be the problem, but maybe it was because I misunderstood some of the concepts, as Im still in learning process. 

    You did not mentioned this requirement before and it's another thing that disqualify complex chain / shape to be used, because by definition, all content has to have the same symbology.

    Actually this requirement is pretty important for me. To fully explain what I´ve tried to achieve was:

    • To have a complex shape containing complex chains(with multiple lines) and lines.
    • Sometimes I want to change linestyle for lines of my complex chains. I´ve tried this with VBA, but it didnt change the graphics for my lines "externally". When I looked at the element, everything was with the same linestyle, but when I selected one of the 4 subelements my element has(2 lines,2 complex chains), then my changed linestyles appeared. I used rewrite on these lines with new linestyle being applied. However, when I unselected the element, the changes were back to normal. I found out that by changing symbology also on one of these 4 base child elements causes the changes to appear normally, however, this is where the "connecting line" appears (As yesterday I managed to write code that manages the creation in OK order, but the "connecting line" was invisible when element was unselected. After I changed linestyle to one of the 4 subelements(or one of the 4 subelements was selected), it appeared again. By term "connecting line" I mean the weird line that made me start this question. 

    At first I thought it will be a good idea with this approach of using nested complex elements, even though I´m still learning a lot, but didn´t expect it to be that difficult to handle (or impossible), as in my head it looked like a good idea. 

    Here is also picture showing my progress of new behavior (that the line is not visible when entire element is selected, but when I select or change symbology for one of the sub elements it appears). The line is also reacting to whenever I hover over it with my mouse, as I hovered over the element, I can even click it when I see the element started to highlight.

    Or in CW order

  • At first I didnt think that could be the problem, but maybe it was because I misunderstood some of the concepts, as Im still in learning process.

    In fact, what elements to use to represent "object" is in my opinion one from the most ignored topic. It's probably it's not described anywhere and what is "dictated by DGN format and API" is fine in the most of situations. And what approach should be used is really "learn by mistakes" process ;-)

    To have a complex shape containing complex chains(with multiple lines) and lines.

    We know now that it's not possible and when nested structure (lines + another complex chains) are required, the only way is to use cell as grouping mechanism.

    Sometimes I want to change linestyle for lines of my complex chains.

    You can change linestyle of the whole chain, not of individual elements in the chain. Complex chain (and complex shape as well) is treated as one element with unified symbology. It's another different from cell, where every element can have own symbology (when graphic cell is used).

    I´ve tried this with VBA

    Please share code and/or DGN file. To explain code by words is confusing. Frankly, I skip such descriptions.

    At first I thought it will be a good idea with this approach of using nested complex elements

    At first you have to collect all requirements, e.g. whether it's expected it will be edited by user or by code only, using what code, whether it will be exported to some other format etc. Often, when they are known, it shows directly what element(s) can be used.

    but didn´t expect it to be that difficult to handle (or impossible)

    You cannot break what is DGN format limitation, MicroStation limitation and API limitation.

    Sometimes it's possible (because MDL API is quite low-level) to create structures that were accepted in the past, but in newer versions they are not. I think (but I am not sure) e.g. in the past it was possible to create (using API) complex chain were every element has different symbology. Today, MicroStation does not allow it and I think when such element is modified by MicroStation, the symbology is unified automatically.

    Here is also picture showing my progress of new behavior

    It seems you are still trying to create complex shape with complex chains inside. As Jon wrote: When Brien wrote "do not do it, it's not valid", accept it as the fact (even when it may be possible with MDL API).

    Regards,

      Jan

  • You guys were right. I´ve converted it into a cell and the problems are no longer present. Thanks for help.

Reply Children
No Data