[CONNECT U12] Monitor EC data change best practice?

Hi,

this my question is more about best practice, not specifically targeted to C++ or C#. C# is preferred in my current project, but when the solution will be available in C++ only, no problem.

Situation: There is an element with custom EC data attached. The data are available in Properties (Element Information) dialog and can be modified by a user. Such change is saved to persistent storage (DGN V8 file) by MicroStation automatically.

Question: Is it possible and what is recommended approch to monitor such change to be able to react on the change (e.g. to modify the element size/shape/etc.)?

I have not done any testing or research yet, but I can imagine that XAttribute changed event is fired when EC data are changed, but it seems to me a bit complicated (go through the whole path from XAttribute, test whether it's EC data or not and to what element it belongs). Maybe there is some other solution available, e.g. to monitor EC data particularly or to hook system responsible for rendering EC data in GUI?

With regards,

  Jan

Parents
  • Hi Jan,

    We have internal native way to monitor changes to XAttributes that store ECInstances.  Those APIs are not exposed yet. It may significantly impact performance of Microstation especially while processing bulk elements containing ECInstances. 

    Still, can you please file an idea. I will connect with you for more inputs on that idea.

    Btw, you can explore Bentley.ECObjects.UI.ECPropertyPane.OnPropertyValueChanging. This delegate fires up when you try to change any property from property pane. It gives you beforevalue and after value. You can reject afterValue by returning false. 


    This is a test

  • Hi Mangesh,

    We have internal native way to monitor changes to XAttributes that store ECInstances.

    Ok, thanks for such information.

    When talking about XAttributes and ECInstances, what is your recommendation (complexity, performance):

    • To check XAttributeId directly to do "quick test" whether it is used to store EC data or other custom data  (I remember there are 4 different IDs used to store EC data as XAttributes).
    • To use some EC API function to test whether element has attached EC data or not.

    Note: It's just immediate thought, I have not done any further test or research in this are yet ;-)

    Those APIs are not exposed yet. It may significantly impact performance of Microstation especially while processing bulk elements containing ECInstances. 

    I understand, it's always quite risky to expose any "monitor a change" API, especially when the most of developers (at least it's my experience) do not think too much about performance impacts and do not follow "escape early" practice.

    In the meantime I thought more about possible solutions and I have an idea how to implement such monitor, something like to monitor changes using ITxnMonitor, apply quick test whether it can be element and data interesting for me (fortunately in this specific case I am interested in only graphic cells and one particular schema, so 99.9% of monitor changes will not pass for further testing and processing).

    I will have also implement event passing from native code ot managed (because businees logic is implemented in C#), but I did it in the past already, when I implement own XAtribute change monitor when it was not available in NET in older API version(s).

    Still, can you please file an idea.

    Yes, I will do, but probably after I will try to implement my own solution to receive some experience and to be able to formulate my idea / request in more precise way ;-)

    Btw, you can explore Bentley.ECObjects.UI.ECPropertyPane.OnPropertyValueChanging.

    Great, I will investigate this option also!

    I expected there should be some place when GUI events can be processed, but without such note it would be hard and time consuming to explore classes and methods in EC API assemblies.

    With regards,

      Jan

  • Hi Jan,

    When talking about XAttributes and ECInstances, what is your recommendation (complexity, performance):

    I will stick with EC APIs. However XAttributes should be faster. You can try out managed APIs as available in Bentley::ECXAttributes.dll. However, if you use XAttributes directly, I will worry about internal EC events that takes care of explorer, properties and many other functionalities that depends on EC. 

    In the meantime I thought more about possible solutions and I have an idea how to implement such monitor, something like to monitor changes using ITxnMonitor, apply quick test whether it can be element and data interesting for me (fortunately in this specific case I am interested in only graphic cells and one particular schema, so 99.9% of monitor changes will not pass for further testing and processing).

    You are right here. Transaction monitor or element change events to monitor changes in XAttribute could be possible ways. There is one more way you can try out, *InstanceChangeRecords*. I am busy right now, may be early next week, I will try to gather some sample code snippet for you. 

    Thanks,

    Mangesh


    This is a test

  • Hi Mangesh,

    thanks a lot for your answer!

    However, if you use XAttributes directly, I will worry about internal EC events that takes care of explorer, properties and many other functionalities that depends on EC. 

    Hmmm, that's very good note, it's easy "for us from outside" to forget that there is more things hidden under the surface ;-)

    There is one more way you can try out, *InstanceChangeRecords*.

    It seems it's not documented, I found only DgnECInstanceChangeRecordsR usage in ContraintHandlerBase.h.

    I am busy right now, may be early next week, I will try to gather some sample code snippet for you. 

    It would be great, I think not for me only. But it's not time critical, the feature based on EC change monitoring is now "nice to have" whereas we are working (and will be for next few weeks) on basic functionality and evaluation some further ideas and concepts for the developed application.

    With regards,

      Jan

Reply Children