|
|
|||||||
Hi All, Does anyone know of a method to properly dispose of a form in KiXforms classic? I've tried to use .dispose or setting the variable to nothing but I have no luck, the memory is not released. I've even tried recursing through the controls and tried to dispose all of the child controls before disposing of the parents, but again I had no luck. This is a problem for me as I have a pretty large application where people can open up forms that have lots of controls. What can happen after repeated usage is that the GUI goes gooey and I'm pretty confident it is due to memory usage. I'm 95% percent confident that this is simply a bug in KiXforms that I won't be able to escape... but you never know. If I'm truly lucky Shawn may have something to say Just step through this code and watch task manager, the memory just keeps going up and up. Code: Break on $s = CreateObject("Kixtart.System") Debug on For $i = 1 to 100 $f = $s.Form $f.Dispose $f = "" Next Any ideas? |
||||||||
|
|
|||||||
Did you try Code: $s = CreateObject("Kixtart.System") Debug on For $i = 1 to 100 $f = $s.Form $f.Dispose $f = "" Next $s = "" Just to see if the memory is cleared up ? |
||||||||
|
|
|||||||
Hi Arend, I hadn't until now, but it still doesn't make a difference. In any case, killing the system object would kill the main form of my app so it wouldn't be feasible. I have noticed that the working set memory usage of my above example is quite different between my workstation at work and my laptop at home. The memory increase for each form is much greater on my work computer. My work computer has 3 monitors so that may be a difference. Regardless it still a problem on more than just my work machine. |
||||||||
|
|
|||||||
Well, I would have expected clearing the $s variable to at least release the memory used by KiXforms, but seeing as that didn't happen I would not expect KiXforms to be the problem but KiX itself, did you try another KiX version? You might have a different KiX version on your laptops and workstation as well? |
||||||||
|
|
|||||||
Hi Arend, It is the working set memory associated with the process that is building up, not the private working set of the kix executable. Maybe someone with better understanding of how COM memory works could jump in here. The way I figure it is that the memory that is growing is the sole domain of the KiXforms dll and it is not releasing its resources as it should. I think the dll's memory is only unloaded once the parent process actually terminates. I believe this as the undelying dll remains file locked until the parent process exits. Regards, Richard |
||||||||
|
|
|||||||
I ran into similar issues not too long ago... http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=203747 |
||||||||
|
|
|||||||
I know my memory is not what it used to be, but indeed, if you destroy the forms and in this case also the system-object, the memory should be released. why you don't see it happening with this example might be because windows doesn't need the memory, so the cleaning of excess memory from kixtart/kixforms process is given low priority. we did run into memory issues with my bbchecker years back and indeed disposing a form or just reusing it instead of creating a new one did change the memory usage. |
||||||||
|
|
|||||||
Thanks Lonk, reusing forms may be the answer. |