It's quite similar to https://communities.bentley.com/products/programming/microstation_programming/f/microstation-programming---forum/201080/mstn-ce-u14-vba-and-com-interop-does-not-release-memory but this time it happens while accessing child elements.When I run this code and do 1Mio Runs, my memory does not get released:
CellElement element = comApp.ActiveModelReference.GetElementByID(elementId) as CellElement; for (int i = 0; i < nRuns; i++) { ElementEnumerator subElements = element.GetSubElements(); while (subElements.MoveNext()) { //... } }
My DGN only contained one Cell Element with 7 Shape Elements. Nothing fancy or special. I was able to exhaust all my RAM with this simple function. A DGN change did not released the memory either.I've tested this on 10.16.02.34 and 10.17.01.62 and both behaved the same.
Jean-Pierre Hundhausen said:memory does not get released
It looks like you're writing a C# AddIn that calls the VBA/COM API. You're fighting two different models of memory management: VBA's reference-counted COM pointers and .NET garbage collection.
Why do that? MicroStation CONNECT provides a first-class .NET API. What can't you do with .NET that necessitates calling VBA methods?
Having said that, what happens if you add this line?
element = null;
Regards, Jon Summers LA Solutions
There is no issue using the .NET API for new Code but there is also old V8 Code that would require more work to convert fully to the .NET API, while avoiding converting back and forth from COM to .NET. Calling
Mit freundlichen Grüßen / Best regardsJean-Pierre Hundhausen
| AB_DATE Engineering Software | ab-date.de |