Hello, I have a following problem: weird behavior is happening on Opencities (link to question,https://communities.bentley.com/products/geospatial/desktop/f/bentley-map-forum/238486/changing-scale-of-a-cell-causes-the-subelement-line-linestyle-scale-to-change-as-well). As I got no question, i had to pick a thorny way of code workaround. My idea is :
For some cells, this approach worked. However, I found out strange behavior.
MSElementDescrP descrP; //lets say this is my element descriptor EditElementHandle handle(descrP, false, false); TransformInfo info(*userTrans); int res = handle.GetHandler().ApplyTransform(handle,info);
In some cases (I don't know what causes this behavior) the address of element descriptor changes. Not only that, but if I check the structure of the original descriptor(that is, before it calls ApplyTransform method), the first element link totally disappears - it is set to NULL(firstElem). EditElementHandle contains element descriptor with whole new address and first element is there correctly(also on new address). I understand that the EditElementHandle is smart wrapper around old C style element descriptors, so it may handle some move inside movements and allocations. That should be fine.
As I work with older code base, that has many functions that work with element descriptors, I was forced to get the new element descriptor from the EditElementHandle(via getElementDescrP() function)
Everything is fine, however! When I add the said element descriptor to the model, suddenly two elements appear: the original non changed cell and then the new version with adjusted scale. Why is that happening when i work only with the new element descriptor ?
Thanks for any kind of input.
Lubo B said:I have a following problem
In which version (e.g. v10.x.y.z) of MicroStation? Use key-in VERSION to see the version no. in the MicroStation Message Center, or Help→About MicroStation in the backstage.
VERSION
See this blog that shows you how to obtain MicroStation's version number.
If you're using an additional product (e.g. ProjectWise, OpenXxx) let us know about that too!
Regards, Jon Summers LA Solutions
I apologise, i mentioned it in the original question but forgot on this one. Im using OpenCities Map Advanced update 16 [10.16.2.14]
Lubo B said:When I add the said element descriptor to the model, suddenly two elements appear: the original non changed cell and then the new version with adjusted scale. Why is that happening when i work only with the new element descriptor?
As you mention, ElementHandle and its inhertied classes is a smart pointer that manages a MSElementDescr.
ElementHandle
MSElementDescr
When using a MSElementDescr, the programmer is responsible for memory management. However, if you 'borrow' the descriptor from a ElementHandle, you must acknowledge memory ownership. One approach is to make the EditElementHandle own the descriptor.
EditElementHandle
If you want to modify the descriptor directly, then use EditElementHandle.ReplaceElementDescr to pass the modified back to the handle that thinks it owns that descriptor. Don't try to take over memory management of that descriptor — let the handle do the work.
EditElementHandle.ReplaceElementDescr
I'm sure that Brien Bastings could add more incisive commentary.
But i didn't want to replace element descr of the Handle. I initiated the handle with the descriptor I had(the original Cell), however after I applied transform, the descriptor inside Handle changed (all addresses) and my old original descriptor lost reference to first element. That way i couldn't iterate through it to get to the line subelement. Thats the reason i extracted the new element descriptor from the handle (with all references), freed the old one, and worked on the new one. However when i added it to model, 2 elements appear - the old original one without changes and the new one with applied changes.
HI Lubo,
my experience of this topic is limited, but I guess Jon is right: You must be careful about descriptor ownership.
An idea: You create EditElementHandle from descriptor, but you do not pass the ownership to the handle, so it is not freed automatically, when new one is created. I have no idea what happens with the old one, but can you try to pass the descriptor to he handle including the ownership, do what you need with the handle and obtain the new descriptor (you must check if Get or Extract suits your needs better).
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Lubo B said:Iterate through the cell header to find its child elements
The 21st century way to do that is the ChildElemIter class. Here's an introduction. There's a writable ChildEditElemIter too.
ChildElemIter
ChildEditElemIter
Update to this issue!
I found out reason why double element was spawned, that was on me. 1 my own callback got called and I did not notice it.
The thing with the ownership and address changing mechanism didn't change though, I still don't understand what circumstances cause the element descriptors to be reallocated by EditElementHandles when I apply transform. It would be nice to know some kind of connection, to see why its happening in the first place.
Yes! I think i saw another one of your comments on different thread and you were also mentioning this. I still need to update lot of the codebase logic to support the new style of handling elements.
Hi Lubo,
Lubo B said:I found out reason why double element was spawned
thanks for sharing the information solved the problem and about the source of it.
Lubo B said:It would be nice to know some kind of connection, to see why its happening in the first place.
In my opinion (but I may be totally wrong ;-) it is not the right way of thinking: As Jon mentioned, to understand the descriptor or element ref ownership is crucial, and EditElementHandle description focuses to this topic in detail.
The descriptor and/or element ref are internal data structures, encapsulated by the handle class. When any modification is done using the handle, an interacting with the internal data is OOP principles violation (the class knows the best what to do internally). When ownership must be changed for any reason, it should be always treated as a new information, with no relation what was in the past.