• State Not Answered
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 939 views
  • Users 0 members are here

In VBA Compress DesignFile no longer clears memory in Microstation Connect 10.15.00.74, is there another method to clear memory between successive file open operations?

Robert Ness
Offline

I had written a replacement batch application for Microstation v8i that allowed for external Excel control, logging, and even an undo, but this application was predicated on the ability to clear memory between successive file open operations.

In v8i this was simple, all one had to do was call the "Compress" command with all options off and Microstation released the memory that was used  by that file. In Connect however this no longer works whether the "Compress" command is called by VBA, or done manually, with all option on or off. Is there another way to force Microstation to release memory between file open operations?

Is there an MDL function that can do this? If so can someone show me how to write the declaration to use in VBA? I do not have access to the MDL function reference.

The reason I must clear memory is that by the time my batch application gets to the 30th or so file in the batch list all memory is consumed so Microstation crashes. Again to reiterate this was NOT a problem in v8i.

I'm aware that VBA is not an inefficient language but it the only one I have access to, and currently the only language I know. There were so many simple things that worked in v8i that no longer work in Connect, such as the big foobar in the "GetElementByID" method. It now gets the parent element and not the element itself (if it is a child element). Microstation Connect has been/is very frustrating from a VBA stand point.

Thanks for any insight.

  • 0 Offline

    Hi Robert,

    Robert Ness said:
    for Microstation v8i that allowed for external Excel control

    Is it code, running in MicroStation (mvba), and accessing Excel, or vice versa, it's Excel macro, accessing MicroStation?

    Robert Ness said:
    but this application was predicated on the ability to clear memory between successive file open operations.

    In general, no application can be responsible for cleaning of memory, belonging to another application.

    And VBA should clear own memory automatically, when the code is written in the right way.

    Robert Ness said:
    In v8i this was simple, all one had to do was call the "Compress" command with all options off and Microstation released the memory that was used  by that file.

    Compress tool is not related to memory cleaning / release in any way! Maybe, such side effect can exist in some situations, but Compress (only) remove unused data from DGN file. Nothing more, nothing less.

    If used to clean memory, iit was used in a wrong way in my opinion.

    Robert Ness said:
    Is there another way to force Microstation to release memory between file open operations?

    MicroStation does it automatically every time automatically.

    Of course, when a bug exist, it can cause memory leak. And you use quite old version, so maybe you find such, not fixed in this version yet. But the last such bug I recall, was 1104232, and it was fixed in the version you use.

    Robert Ness said:
    Is there an MDL function that can do this?

    No such function exist, because it does not make sense. Correctly written code clean memory automatically. When it does not happen, it is bug.

    Robert Ness said:
    such as the big foobar in the "GetElementByID" method

    What do you mean by "big foobar"? I do not recall any othe bug than reported in the mentioned 1104232 defect.

    Robert Ness said:
    It now gets the parent element and not the element itself (if it is a child element).

    Actually, it is not bug in fact ... or better to say it depends on language used and perspective.

    Some crucial workflows and philosophy behing operations changed in CONNECT Edition, and how complex elements are seens and treates is one from important ones. It the topic for another (and long, probably not fully objective ;-) discussion, but now complex elements are seens as black boxes, when to access its content extra steps are required. I think it relates also that internal mechanism, how MicroStation work with DGN, has changed a bit.

    Robert Ness said:
    Microstation Connect has been/is very frustrating from a VBA stand point.

    Hmmm ... I don't think so, even several such individual changes and issues exist. But it's not about the whole VBA.

    The problem of MicroStation VBA is that it's old, formally unsupported (by Microsoft), and not actively developed (by Bentley Systems) limited user tool. For nothing else than simple script or not very complex tool, it's probably not the right tool to be used.

    Robert Ness said:
    I'm aware that VBA is not an inefficient language

    It's not so bad, a bigger problem is that there are not many tools how to control VBA memory management, and at the same time it is very simple to write dirty code, consuming memory in very bad way (which is multiplied by knowledge of VBA users and often poor quality of tutorials).

    Robert Ness said:
    Thanks for any insight.

    When VBA code repeats an intensive operation (like scanning design file) and / or working with GUI (e.g. using one or more VBA Forms), it is always fully responsible to be "tolerant" to MicroStation and allows it to manage all background / internal tasks. It's not new for CE, but mandatory rules for VBA applications in general.

    You mentioned your application is "a batch processor", so I assume you open design file, do something, close it and repeat the steps again. In such case, do you:

    • When a design file is openend, do you wait for MicroStation idle state? To open deisgn file is very complex process, still running even when a mode content is displayed already on display and API is ready to be used.
    • In the same situation, plus after any intensive work, do you allow (especially when a form is displayed) MicroStation to process operations in queue? Which means to call DoEvents method regularly?

    With regards,

      Jan

    Bentley Accredited Developer: iTwin Platform - Associate
    Labyrinth Technology  |  dev.notes()  |  cad.point

  • 0 Offline
    I appreciate the response as unhelpful as it may be. At any rate, you did bring about salient point about defect 1104232. I tried to duplicate the error with similar test code and can assure you that it was not fixed. I believe this is my exact problem.
     
    My code:
     
    Sub Test_Memory()
            Dim ee As ElementEnumerator
            Dim oElem As Element
           
            Set ee = ActiveModelReference.Scan
           
            Do While ee.MoveNext
               Set oElem = ee.Current
               Set oElem = Nothing
            Loop
    End Sub
     
    Sub Test_RunMem()
        Dim i As Integer
       
        For i = 1 To 1000
            Test_Memory
        Next i
        Debug.Print "Done"
    End Sub
     
    When I ran the “Test_RunMem” on my 10.15.00.74 version, and with the file I used, Microstation immediately jumped to over 12gb of memory use. I will check to see if our company is testing a newer version of Microstation for distribution. Fingers crossed.
  • 0 Offline in reply to Robert Ness
    Robert Ness said:
    When I ran the “Test_RunMem” on my 10.15.00.74 version, and with the file I used, Microstation immediately jumped to over 12gb of memory

    What is in subroutine Test_Memory? If there are no calls to MicroStation VBA you can run the same code in, say, Excel.  That would provide corroborating evidence to help convince the Bentley developers that something should be done.

     
    Regards, Jon Summers
    LA Solutions

  • 0 Offline
    Jon,
     
    I’m not quite following, are you saying I should try a similar object assignment in the Excel VBA IDE and see if it results in a similar level of memory usage? Or create an Excel object in the Microstation VBA IDE and try something similar?
     
    Did you try this code in your, I assume newer version, of Microstation and see similar results as myself?
     
  • 0 Offline
    Jon,
     
    I did try a similar bit of code in the Excel IDE by just assigning a column to an object variable in an external loop set for 20000x and although there was a spike in my CPU usage, as expected, memory use did not change.
  • 0 Offline in reply to Robert Ness
    Robert Ness said:
    Did you try this code in your, I assume newer version, of MicroStation and see similar results as myself?

    I didn't try it, for the simple reason that I believe you.  VBA is, as Jan mentioned, 20th century technology.  It was designed as a rapid-application- development (RAD) tool, which it does very well.  It was not designed to handle memory efficiently.  It was not designed for performance.  If you want either of the latter, then choose a different programming language such as C++ or .NET.

     
    Regards, Jon Summers
    LA Solutions

Communities
Support and Services
Training and Learning
Social Media