[CONNECT C++] Element Handlers

Hi all,

First of all, let me apologize in advance if this comes across as a little incoherent. I'll do my best to state what I am trying to achieve.

I am trying to develop an application that can place a series of cell elements linearly. Which is easy enough, and I can accomplish this no problem.
I would then like to be able to use the standard MicroStation selection tool to select one or all of my series of cell elements and for MicroStation to display my own custom manipulators on top of these elements (I believe this can be done using view decorations and transient elements, etc.).

What I don't quite get is what is the best way to recognize these elements as a special type of element that should display my manipulators while my application is running.
Do I need to monitor element selection events and check each cell element for some piece of data that tells me that it belongs to my application, and then create the manipulators on screen.

Or, preferably, can I use the element handler classes to create my own special type of element (which inherits from cell elements) that I can provide callbacks to my own functions to handle displaying manipulators, etc.

Any pointers as to where I can find more information would be great.

Thanks
Liam

  • Unknown said:
    I would like to be able to use the standard MicroStation selection tool to select one or all of my series of cell elements

    When you implement a tool that inherits from the DgnElementSetTool base class, you gain the ability to react to selection sets, fences and user pick operations.  It's documented in the MicroStationAPI help and some of the examples delivered witht the CONNECT SDK show how to use it.

    Unknown said:
    what is the best way to recognize these elements as a special type of element

    There are various ways that you can tag an element.  Adding or reading an XAttribute is straightforward.  Read about XAttributes in MicroStationAPI help.

     
    Regards, Jon Summers
    LA Solutions

    Answer Verified By: wilks 

  • Hi Liam,

    in my opinion there are several independent development topics mentioned in your post and they can be discussed, implemented and tested separately:

    Unknown said:
    Or, preferably, can I use the element handler classes to create my own special type of element

    As far as I know it's not possible to implement own ElementHandler for normal 3rd party developers. The handlers define MicroStation elements behavior, so to create own one predicates to introduce own element type ... and it's probably what is not supported (and what is quite bad idea in my opinion).

    Unknown said:
    that I can provide callbacks to my own functions to handle displaying manipulators, etc.

    You can do it (not sure if for all scenarios) with existing API also.

    Unknown said:
    Any pointers as to where I can find more information would be great.

    Ideas presented by Jon is the way you should think about.

    And some my ideas (and mostly ideas only, because I have not done similar topics in CONNECT Edition yet):

    • To create "own type". I agree with Jon XAttributes can be the right solution. It allows to add own data in own structure, so you can easily identify if a particular cell is your element or not. To use XAttributes, you have to ask Bentley for IDm so you data can be identified. Alternatively you can create ECSchema and attach ECClass instance to elements. Advantage of ECSchema approach is no ID is required, because data are stored as XAttributes with "ECSchema" ID and you can also utilise an ability to display some data in a standardized way in Properties dialog (e.g. to override element type name "Cell" by own one "My element type").
    • To identify own type. Try to implement e.g. modification tool to verify you are able to locate all related elements based on one identified.
    • To monitor Select Element tool (changes in selection set). I am not sure how to use DgnElementSetTool to monitor if selection set was changed, but I assume there is some way using ElementAgenda and own listener. In the past it was possible (and I guess it still exists in CONNECT Edition) using mdlLocate_setFunction and LOCATE_SELECT_CMD.
    • To add own manipulators: Have no idea there, but view decorators seem to be the right way (transient elements are obsolete).

    With regards,

      Jan

    Answer Verified By: wilks 

  • That sounds like the logical way to handle things and a relief as it is something I can understand. I will read more in the SDK help and examples.

    I still have not got my head around Element Handlers and thought there must be some paradigm i'm missing that would help me do what I'm trying to do.

    I'll take a good look at XAttributes and\or Jan's suggestion of EC Objects also.

    BTW, I love your website. It has been a treasure trove of information for me for many years.
  • Thanks Jan. I like your idea regarding EC objects. I will look into that also.
    Using ElementAgenda and it's own listener seems like a useful clue also.
  • Hi Liam,

    Unknown said:
    I still have not got my head around Element Handlers and thought there must be some paradigm i'm missing that would help me do what I'm trying to do.

    I agree it require some time to "become compatible" with common "handler approach". I found this summary in some older BDN presentation about "Handler pattern". maybe it can help you to adopt the concept of handlers easier:

    • See “Flyweight” pattern in Design Patterns* (Gamma, Helm, Johnson, Vlissides) ... My note: Design Patterns book written by "gang of four" is a kind of bible of OOP development, especially if C++ is used. In my opinion it's "must read" for any OOP developer.
    • Handler supplies implementation but not data
    • Generally a pure-virtual baseclass
    • Examples: ElementHandler, ViewHandler, XAttributeHandler, etc.

    ElementHandler:

    • “Handler” pattern for MicroStation Elements
    • Dictates entire behavior of “type” of Element
    • Controls lifecycle (create, copy, delete)
    • Non-trivial implementations
    • May be used by Applications, but to implement an ElementHandler requires a “license”

    I am not sure how thight the implementation is and how it changed between V8i and CONNECT Edition, but general idea is probably still the same: All elements of the same type have always the same behaviour. To implement every element as "full object" (let's call it naive implementation) leads to memory wasting. The flyweight pattern helps to split what is specific (element data) and what can be shared.

    With regards,

      Jan