[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 Reply
  • I am not sure whether your reaction is that my formulation (i-model is read only) is wrong or you disagree with the concept or read only repository in a context of e.g. BIM workflow

    Yes to both. The info provided via i.dgn or I.model may start out being read only, but this will often (almost certainly given long enough) be written to as well when it is consumed by another. Taking the position that it is read only is neither here nor there. It is not the End of the Story as you say, rather the beginning. An i.dgn provided by a designer will be amended by the cost estimator, when he adds the cost rates. An i.dgn with terrain info will be amended by others like a geotechnical or health and safety engineers when they consume the info. This will need happen interactively and tracked.

    ConceptStation product

    Exactly. My understanding is that they are using the SQLite format. So, write as well as read. I think that Navigator Mobile also must have some write capability as it is being used to take notes on site.

    iModelJS, next generation of i-model,

    Again, I think that you are mistaken. OpenPlant is transitioning to Imodel.Hub.

    Technically there is nearly no difference between .dgn and .i.dgn

    I think that we are talking past each other. The difference as far as the user is concerned is that the 'business' and other information that is provided by the vertical is converted to Items and can be read without the need for the originating app. The geometry is important but secondary in this case. ADSK's Object Enablers also provide something similar.

    One problem that is already manifest when everything is 'read only' is the cack-handed way Bentley handles objects that have been generated by a vertical, when they are are referenced or opened in another app. They can not be manipulated in any way (Element Handler(?) blocks the Mstn Move tool for example). So, a component generated by a vertical can not be moved into its correct position unless the originating app is loaded, turning it into a 'zombie'.

    In context of MicroStation the question does not make sense, because i-model is read only, so no change can be propagated to this format after it's created.

    This sentence does not make any sense as your premise is erroneous. SQLite is a relational database so is designed to take writes... just like .dgn.

    And yes, leaving aside the question of whether writes should be allowed, there are many read-only applications.

Children