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?
Dominic Seah said:I don't think this is correct at all. If you look at most BIM workflows
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.
Technically, i-model in Power products is read only, regardless .i.dgn or .imodel is used. End of story.
I do not know how i-model is used in ConceptStation product, my assumption (but I have nearly zero knowledge here) is they used i-model in different way as standard repository.
But e.g. iModelJS, next generation of i-model, is also strictly read only format, and modifications are stored as "change transactions", so from users' perspective it looks like read/write format, but it's not. This approach is not new and is used by many products, probably all code repository and versioning systems (where Git is I guess direct inspiration for iModelJS) work this way, also Adob Lightroom stores all picture modifications as a chain of time ordered transcations, but original data are never modified.
Dominic Seah said:So, there is a big difference between a dgn and i.dgn which has all the vertical's information exposed.
Technically there is nearly no difference between .dgn and .i.dgn, the format is the same, but as Jon wrote, data is converted into different structures when published to i-model. It's primarily about data optimization, but not primarily about format change: e.g. SmartSolid is converted from complicated structure storead as cell with huge amount of custom data to standardized representation, vertical applications convert data from proprietary UserAttributes and XAttributes structures to EC schemas and EC classes. They can do the same when working with original DGN, but from historical and subtle technical reasons they do not in current versions.
Dominic Seah said:it is faster/more efficient to use this format to monitor and react to changes?
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.
P.S. It seems we have gone far from my original question....
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Dominic Seah said:So, how do explain i-model Transformer?
As far asI know, i-model Transformer is designed similarly to ETL (Extract Transform Load) tools: No change is done at original data, but data are read, transformed (converted, merged with another sources etc.) and saved to new "data version" with own provenance information.
Dominic Seah said:That's why there needs to be some tools to help persist and manage / resolve changes...
I think that's one from main topics behind iModelJS.
Dominic Seah said:Sticking your head in the sand does not help.
I do not understand this comment and it seems to be offensive a bit.
Because we are in programming forum, as developers we can discuss what is possible to do and what is possible to implement using existing APIs and what features are allowed by used formats. Nothing more, nothing less. We depend, or better to say we choose to depend ;-), on what Bentley decides that is the best to fulfill their business strategy.
Of course there are alterantive solutions (every new product tells it solves all existing questions and issues ;-) and ideas how existing need can be solved, but in my opinion it's beyond scope of this forum. Fortunately anybody can go and to investigate own technology, but because after so many years there is still no technology that beats other and conquers the world, it's probably extremely complicated at the same time to design it, to implement it in acceptable cost and be able to sell it.
Jan Šlegr said: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.
Jan Šlegr said: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.
Jan Šlegr said: iModelJS, next generation of i-model,
Again, I think that you are mistaken. OpenPlant is transitioning to Imodel.Hub.
Jan Šlegr said: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'.
Jan Šlegr said: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.
.i.dgn-based iModel is read-only. sqlite-based iModel is all about change, in pretty much exactly the way Jan describes, therefore not read-only. But MicroStation does not allow directly editing it. iModel.js can be used to create apps which treat the iModel as read-only or allow editing it. Navigator Mobile does not write to the iModel; its saved views, annotations, etc are saved to a separate location shared amongst users of a project. ConceptStation does write to the iModel.
None of this discussion is helping to answer the original question.
So, SQLite-based I.models allow change. As does .iModel.js.
Question for Paul regarding change monitoring:would this be easier / faster using SQLite based i.models?
Dominic Seah said:regarding change monitoring:would this be easier / faster using SQLite based i.models?
Please post a new question. We've deviated a long way from Jan's original question.
Regards, Jon Summers LA Solutions
Jan Šlegr said: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.
Jan Šlegr said: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 a lot for your answer!
Mangesh.Shelar said: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 ;-)
Mangesh.Shelar said:There is one more way you can try out, *InstanceChangeRecords*.
It seems it's not documented, I found only DgnECInstanceChangeRecordsR usage in ContraintHandlerBase.h.
Mangesh.Shelar said: 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.
FWIW. While pending Mangesh's reply related to:
In case you like to try to run with that further, here are two (potential) breadcrumbs I found that may help you explore this path.
C:\PROGRA~1\Bentley\MICROS~2\include\Mstn\Constraint2dElement\ConstraintHandlerBase.h:258: CONSTRAINT2DELEMENT_EXPORT virtual void _GetPotentialInstanceChanges (DgnECInstanceChangeRecordsR changes, DgnECTxnInfoCR txns, DgnECInstanceCreateContextCR context) const override;
And an Environment Error (callstack) post.
You can try this approach:
myECProperty.Validator = new IECValidatorDelegate(myValidator);