[MStn CE U16 C++] Bug? It's possible to create DgnLink on locked element?

Hi,

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

DgnLinkManager::ReadLinkTree(*treeSpecPtr, true);

returns nullptr when no link exists yet on element and should be created a new one. Or, alternatively, something will be reported by

DgnLinkManager::WriteLinkTree(*linkTree);

Is it WAD and DgnLinks structure can be created regardless it's locked (read-only) or not?

With regards,

  Jan

Parents
  • 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?

    Regards,

      Jan

  • 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 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

  • Hi Jon,

    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.

    Somewhere in the DGN file is a collection of XAttributes

    As far as I remember, XAttributes are stored in own stream in DGN file.

    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 ;-)

    With regards,

      Jan

  • 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.

    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.

    It would be nice to know it officially

    I agree!

     
    Regards, Jon Summers
    LA Solutions

Reply Children
No Data