C# How to get complex shape components from an Element located via Fence/ElementAgenda

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.

Parents
  • 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?

  • Hi Paul,

    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

  • 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.

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

  • 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.

    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.

    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

  • Hi Paul,

    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.

    Yes, I am aware of this change and it's good to know that my feeling / observation is correct.

    I have to comment that in my opinion Bentley failed to explain this "philosophy change" to 3rd party developers. The concept of ElementHandlers were introduced long time ago (not sure, maybe 7 years?), but I don't recall any presentation that explain not technical API details, but concepts. So it's not surprise so many people still thinking in terms of data structures (aka element types and pointers to descriptors) and not in terms of objects that can be accessed through handlers and queried when necessary.

    So thank you (and Brien, Bob and others) for spending your time to answer again and again question when anything is not clear.

    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.

    Good examples :-)

    Regards,

      Jan

  • Hi David,

    some extra comments as addition to Jon's answer ;-)

    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 this is crucial in my opinion to be aware of "an essence of change" (but unfortunately Bentley have not explained in any simple way). This is not about new API, but new approach / concept / philosophy. It's similar when people knowing C migrated to C++, C# or Java and they state they are OOP developers (and their code is object oriented) ... which is typically not true. Until a developer is not able to think in terms of SOLID, design pattern etc, they code will never be object oriented despite of any object language they will use.

    My formulation of this change is "don't work with data and how they are stored, but use services (handlers, queires...) to access objects".

    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.

    It's important to notice that in the past the innovations were implemented using the same API and lanague (C). From MicroStation V8i a new concept were introduced (MicroStationAPI) and whereas I treat V8i C++ API as mostly testing implementation to evaluate whether it's a right way, in CE it has become the primary interface to power platform features.

    In fact CE API is schizofrenic: There is a huge heritage of file formats from ISFF over DGN V7 to DGN V8 and code / applications / tools that do sometimes strange or even bad things, but were great in a historical context (e.g. it has been possible to create complex shape, iterate through elements and to change them to have different attributes: could help a lot in time of 64 levels and limited resources, but ugly and not correct from today perspective). API allows to work in old way (not always, but where MDL functions where migrated, it's probably possible), but it's treated as dangerous. And new API does not allow to do some old dirty things, simply because they are treated as bad today. So there is probably not simple solution and it's about slow movement from old code to applications written in a modern way (but Bentley unfortunately does not do too much to make this process faster and easy).

    I would be surprised if this is not the case.

    New approach does not allow to do everything what was possible in V8i using MDL. Not because the functions are missing, but because the concept is completely different.

    My problem is that I have to find my way around to get where I need to go in a different programming context.

    There are four different scenarios in my opinion:

    • Use old MDL functions when available. But as Paul wrote above, in long term perspective it's bad and in fact you will wrote buggy code. A good example is parametric solid, where access through descriptors does not work (my assumption, have not tested it), because it's implemented as extended element that have no defined structure (in DGN stored as element type 106, but it's not important), and handler provides all necessary services.
    • Find a way how to do the same using new API. This is the best solution I guess.
    • When it's not possible, discuss wheter it's missing implementation or it's "by design". Sometimes discussed situations / workflows make sense, but are not supported well in the current API.
    • When a task cannot be done using new API and it's by design, forget it. Even though it probably sounds like bad solution, my feeling is that Bentley has long term strategy and when iHub 2 (DGN next?) will be released and with new product versions in future more and more old features will be marked as obsolete and will be not supported and will be removed at the end.

    Sorry for long comment...

    With regards,

      Jan

  • Thanks Jan,

    The four scenarios you suggest are helpful. In the new project I am working on I have decided to avoid the MDL platform and see if I can do it all using the c# platform.

    The problem I have, which Jon mentioned is common to all, is wading through the doc files to find what I need. Most of my work is with straight windows apps where there is a mountain of material easily searchable on the net. I find code examples the quickest way to pick things up. The SDK examples in c# are not super abundant. I managed to find a way to do what I wanted through CurveVector and you published an answer about a year ago which helped.

    So I'm pushing on, trying to avoid my old .mc code.

    Thanks again for your comments and information.

    David

  • I have decided to avoid the MDL platform and see if I can do it all using the c# platform.

    Honestly ... you cannot. NET API is not equivalent to C++. Quite a lot of features are not available in NET and some C++ constructions are implemented in a different way (e.g. there are no handlerds, but specific classes).

    This is not necessarily a blocker, it dependes a lot on what functionality (and in what memory consumption plus performance) you need to implement. Also when there is e.g. 5% of required functionality missing, it's probably easier to implement own wrapper using C++/CLI than to do everything in C++.

    I agree with you NET development is faster (despite of many developer using C# use it at C# 3 level whereas we have now C# 7.2) and also NET APIs are often easier for learning. But in the case of MicroStation, beside feature limitation, there is a cost of higher memory consumption (objects exist in native memory and are marshalled to managed classes) and lower performance (cost of marshalling between managed and native). So for intensive design file data tasks it's probably not good idea to implement it in managed code (when naive not optimal implementation is used, marhsalling can be easily 60% of application time), but vice versa placement or normal modification commands can be implemented in NET perfectly.

    With regards,

      Jan

  • My project involves is a fairly small Microstation Element location and extraction process. I chose c# for this task for two reasons: 1. It will interface easily with some windows forms and database interaction; and 2. It is a small task so I thought it would be an ideal opportunity to work through MStation c# and start to get a handle (no pun intended) on the platform.

    The task is up and running now. 

    Others have told me MS c# platform is not as comprehensive as the C++ platform so in line with your suggestions I'll try to find the balance for subsequent more demanding projects.

    With thanks,

    David

Reply
  • My project involves is a fairly small Microstation Element location and extraction process. I chose c# for this task for two reasons: 1. It will interface easily with some windows forms and database interaction; and 2. It is a small task so I thought it would be an ideal opportunity to work through MStation c# and start to get a handle (no pun intended) on the platform.

    The task is up and running now. 

    Others have told me MS c# platform is not as comprehensive as the C++ platform so in line with your suggestions I'll try to find the balance for subsequent more demanding projects.

    With thanks,

    David

Children
  • Others have told me MS c# platform is not as comprehensive as the C++ platform

    True today, but not necessarily true tomorrow.  The .NET API is leaping forward with each MicroStation CONNECT Update.

    When CONNECT was released commercially in 2015 the APIs were not in place for us to port or refactor existing apps. to C#.  Even with C++ we couldn't start until 2017 because vital bits weren't published.  Now, with Update 8, code that had to use C++ can be reproduced using C#.


    Note: I should qualify that to mean either 'not published' or 'published but not visible without spelunking the entire API documentation with no guarantee of success'.

     
    Regards, Jon Summers
    LA Solutions