I am not sure whether it should be recognized as bug, but at least, I am surprised, because I did not expect that ;-)
Normally (using GUI), it's not possible to create / modify / remove DgnLinks, when an element is locked.
But, using API, it can be done without any problem, no exception or warning is reported that data attached to the element is to be changed. At least, I would expect, that
returns nullptr when no link exists yet on element and should be created a new one. Or, alternatively, something will be reported by
Is it WAD and DgnLinks structure can be created regardless it's locked (read-only) or not?
I did some more tests and in my opinion now API breaks the rule that locked element cannot be modified.
Before test code is run, the element is locked and there are no data attached on it:
After the code ran, the element is still locked, but XAttributes are attached on element:
Or, attaching XAttributes (on element) is not recognized as element modification?
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
The MicroStation Lock UI and expectations appear simple, yet handle some additional use case Scenarios/Features; like those defined in MicroStation Compatibility Variables (See: CAPABILITY_ELEMENT_LOCK and CAPABILITY_ELEMENTTEMPLATE_HONORELEMENTLOCK).
So, depending on the state of each of those variables (current workspace value), originating element creation method (element or element template), and modification method (api) different results may occur. I presume these points may not be interfering with your results, but can you check to see and expand on what conditions are being encountered?
standard DGN V8 mode is used, so I guess both mentioned capabilities are not set explicitly (e.g. switched off). I assume in V8 mode, element locking is supported as a standard feature (at least, it can be set and locked elements are recognized by tools).
Jan Šlegr said:Or, attaching XAttributes (on element) is not recognized as element modification?
From MicroStationAPI help: An XAttribute is data that is stored on an element, not in an element. An XAttribute is not part of the element's data (that is, visible through an MSElement). By way of contrast, a user data linkage is part of an element's data.
Somewhere in the DGN file is a collection of XAttributes. An XAttribute knows the DGN element to which it belongs by the element's ID (ElementId). When you add an XAttribute to an element, the API creates a new entry in the XAttribute collection. It doesn't affect the element, because all that happened was that the new XAttribute obtained the element's ID. When you create an XAttribute you're not violating anything.
Presumably, when an element is locked, the UI prevents a user from creating an XAttribute.
If you want to prevent your app. from creating an XAttribute for a locked element, your code should check the MicroStation locks as Robert Hook suggests.
The Element Properties dialog displays DGN element data. Presumably, when you choose an element, the dialog logic checks in the XAttribute collection to find if there are more data associated with the element.
Regards, Jon Summers LA Solutions
Jon Summers said:An XAttribute is data that is stored on an element, not in an element.
It's well known fact. But it's implementation feature, whereas in GUI, XAttributes are displayed as part of element (and also in EC representation, information about XAttributes is part of Element.
So there are two perspectives: GUI vs. implementation, and the question is what rule(s) API follows.
Jon Summers said:Somewhere in the DGN file is a collection of XAttributes
As far as I remember, XAttributes are stored in own stream in DGN file.
Jon Summers said:When you add an XAttribute to an element, the API creates a new entry in the XAttribute collection. It doesn't affect the element, because all that happened was that the new XAttribute obtained the element's ID.
Is it what you think how it works or you have any technical specification available?
I found this issue "just by an accident", so I do not know how other XAttributes-based API functions work. It would be nice to know it officially, whether it is as you wrote (XAttributes creation / modification / removal are not treated as element change) and API always follow this concept, or "it depends".
I agree it's only about proper implementation, and when it does not break general concept (so it is fine to change "locked elements" this way), maybe it opens new possibilities ;-)
Jan Šlegr said:Is it what you think how it works or you have any technical specification available?
It's analogous to tags. When you attach a tag to an element: call mdlTag_create(), passing the host's element ID. The host element is unaffected when the tag element is created.
Jan Šlegr said: whether it is as you wrote (XAttributes creation / modification / removal are not treated as element change) and API always follow this concept, or "it depends".
It's a transaction, whether or not it involves an element change.
Jan Šlegr said:It would be nice to know it officially