We are plotting elements and storing them in a List for reference.. What we have noticed is that when the elements are undone, the "IsDeleted" property becomes True and the IsValid property become false as expected....
However, once we add a new element to the DGN (element.AddToModel()), the elements that we have stored are being replaced one at a time by the newly plotted elements.. (New element ID, IsDeleted = false, and IsValid=true, etc)
This has lead to a verify difficult to pinpoint bug.. Is this intentional design for the API?
Heres a video showing the problem.
https://certainty3d-my.sharepoint.com/:v:/g/personal/mauricio_terneus_topodot_com/ETE2PxxHPVJEmsiiM02NjZkBo8t59EbcdfBcjFf9rVwavg?e=u5vmG3
*Note* I noticed in the video I chained the .GetElementUor() method of my class with the "AddToModel()" method of the returned element, however the change is happening with "AddToModel()" and nothing in my classes are causing this change
Hi Maury,
While I am checking with development to see if we can provide some consistent clarifications and recommendations on this topic...
Can you provide a bit more information on the workflow wrt why your app would hold onto/track a static list of element ids (when originally in design file) and deleted (prior to plotting), then an undo (after plotting - having new "session" element ids assigned)?
Can you create your list at the time of processing/need (post printing) and obtain correct/expected results?
Are these deleted (and re-instated) elements "important and relevant" to "your application" and if so; would assigning your own user application signature ID (we can assign you one) and/or "tagging" elements with (your own) an external instance reference/GUID/UUID be something (additional) needed/required to help ensure locating all (your application) elements needed under these conditions?
I will post you with any information/recommendations we can provide as soon as possible.
Thank you in advance,Bob
Hi Bob,
Example Scenario:
Tool plots point elements and shows a transient connecting between each point.
As part of a QA step, the user has the ability to move, delete, undo, redo the points and the transients will update its self accordingly.
The user also has the ability to insert new points which will insert its self in the proper location (both geographically and its index within the sorted list)
What is happening is that the user can Undo the inserted points, then continue adding more, when this happens, elements that are flagged as "IsDeleted" in our sorted list are now changed to the new inserted point and are no longer considered "Deleted". This also results in the inserted point now being duplicated in the sorted list in the incorrect location..
For now we have worked around the issue by using a similar technique to what you have suggested, but I imagine that other developers will run into similar problems.
Thank you and I'll make sure development is provided the additional workflow details.
FWIW. Using just straight MicroStation - create 3 active points, verify IDs, delete all, undo, and review IDs (same as original). So, it must be something within the particular workflow (e.g. Adding new "highest/next id" elements, then "undo deleted" now needing to do so at a new "highest/next id") you defined/created and we will try to focus on that.
Again, thank you.Bob
Correct, if you delete and undo, the element ID's are correct.
The problem happens when you Create -> Undo -> Create more
This is not possible to recreate in MicroStation alone since you are not able to restore the originally created elements. But if you work with them programmatically, you will run into problems..
Since the element should technically never return, I imagine that MicroStation is recycling the ElementRef, ElementHandle, or similar which is affecting any existing references to the original elements.
In modern MicroStation V8 and CONNECT ElementIDs should be considered "non-colliding session created ids" where new elements are assigned 'next highest" ids available; thus not enabling the concept of persistent element ids (as attempted early on). If all prior session element ids are unchanged (most common/often) they can sort of act like persistent ids however if "your elements" are modified/change then user data linkages, dependencies and (sometimes) PersistentElementPath APIs; can be used for "better element identification" under some often extreme conditions. I'll let you know once I receive some further feedback to pass along.
Thank you,Bob