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

    Performance: this sounds very foreboding. Performance is pretty critical to adoption.

    Would 'monitoring' these changes be quicker in an i.dgn or i.model (which I believe is based on SQLite)?

    Thanks

  • Hi Dominic,

    The non exposed API I have today, if I expose as is, you will start getting callback for every EC xattribute change. So, lets say, you are interested just in your custom schema. Then you need to write a code to filter those attribute that matches to your schema. And, Microstation needs to wait till you complete your processing. Therefore I am saying it may cause performance issue. 

    May be I can make it restrictive like I may fire those events for particular schema or class. Or I may not fire it on multi element selection. Or I may give you options to make it restrictive. I am not 100% sure at this point of time. I need to write good new tests before exposing these APIs.

    Thanks,

    Mangesh


    This is a test

Reply
  • Hi Dominic,

    The non exposed API I have today, if I expose as is, you will start getting callback for every EC xattribute change. So, lets say, you are interested just in your custom schema. Then you need to write a code to filter those attribute that matches to your schema. And, Microstation needs to wait till you complete your processing. Therefore I am saying it may cause performance issue. 

    May be I can make it restrictive like I may fire those events for particular schema or class. Or I may not fire it on multi element selection. Or I may give you options to make it restrictive. I am not 100% sure at this point of time. I need to write good new tests before exposing these APIs.

    Thanks,

    Mangesh


    This is a test

Children
  • Hi Mangesh,

    Thanks for the response.

    It sounds like SQLite would not help, which is surprising since I would have thought that relational databases would have to be able to deal with 'monitoring' quickly and efficiently.

    Callbacks: we sometimes see 'maximum callbacks... ' exceptions. I guess that this is the indiscriminate unmanaged callback avalanche you are referring to.

    Waiting: I hear that AutoCAD devs complain about their apps being hard to debug because they can not tell when AutoCAD is finished processing and is back in 'quiescent' mode. I think that another problem is there may be many subscribers.

    Not sure how the sequencing of the callbacks between multiple subscribers will be managed?

    Marshalling: I think that Revit also provides 'marshalling' to help speed things up. I suppose that there is an equivalent in the database world where queries are re-jigged at low level to maximize caching etc.

    Apparently Revit also checks the propagation of the callbacks before it executes them to see if there are problems (circular dependencies etc). 

    It sounds like you have a lot of tests to do...