Hello,
Xojo 15v4 (but it seems the issue goes back at least one year).
I create a new project with two windows (Document). One is set as visible, the other one as invisible.
The first window contains a push button whose action event says: Window2.show
Once Window2 is open, Activity Monitor shows that the Memory Usage has raised by 1 M.
I close Window2, but Memory Usage does not decrease.
And each time I open window2, Memory Usage increases by 1 M, and closing it, Memory never decreases.
Now, I have an app that every three minutes opens an Activity window, and after a while it closes it.
After several hours, the Memory Usage that at launch was 18 M, shows to be 90 or more M.
Is there a way to release all those megas? Thanks.
If you open Window2 using Window2.show then you probably have ‘implicit instantiation’ turned on.
Thats where Xojo creates a window of the same name as the window class.
It may possibly never be set to nil.
But if memory goes up every time, what do you do in the activate or open events to use the memory?
Try this:
Add a property to the app called mActivityWindow
When you would have used Window2.show, use this instead:
mActivityWindow = new Window2
mActivityWindow.show
By setting the mActivityWindow to a new object, you will release the usage count from the previously used copy, and garbage collection should release the memory.
Tried it, but memory still increases.
BTW, in the real app, I need implicitInstantiation in order to refer to methods and functions between the two windows.
But in the new project I was referring to, window1 contains only a button, while window2 does not contain anything anywhere.
Actually, not true.
You can have global / app level variable of type Window1 and Window2
If mActivityWindow is a global property, then no matter how many times it is created and destroyed, you can access the properties of mActivityWindow
in exactly the same way you can with
Window2
To extremes… you could have 25 Window2 objects in an array!
Each one of them can have their properties and methods accessed …
Then make it #If XojoVersion < 2016 and TargetMacOS
#Endif
EDIT: I put the fix into Feedback. Great start for the year, I was concerned about using windows extensively because of that and installed rather complicated window instance handlers in my projects.
Of course it will. And releasing is currently the only way to solve the problem as Xojo hasn’t addressed this. No offense, but memory leaks should always have top priority and should be fixed immediately. Note that the error was reported in August 2014 and is still not fixed, so one can assume that it will take some time until it will.
and you might have seen it’s marked fixed in Feedback now, which makes me think the condition in the code above wont have to be modified and the fix will be in 2016r1.
I hope it fixes also this corollary problem:
let us assume that before opening window2 memory usage is 20MB;
when the second window contains a pagepanel where the first pane holds 3 objects, the second 7 objects etc, then moving from one pane to panes holding more objects, Memory Usage increases, and after closing the window, memory usage is usually more than 20MB (according to the number of objects in a given pane, it could be 24MB or more).
At present this happens even using:
Declare Sub release Lib “Foundation” Selector “release” (receiver As Ptr)
release(Ptr(Handle))
[quote=239337:@Carlo Rubini]I hope it fixes also this corollary problem:
let us assume that before opening window2 memory usage is 20MB;
when the second window contains a pagepanel where the first pane holds 3 objects, the second 7 objects etc, then moving from one pane to panes holding more objects, Memory Usage increases, and after closing the window, memory usage is usually more than 20MB (according to the number of objects in a given pane, it could be 24MB or more).
At present this happens even using:
Declare Sub release Lib “Foundation” Selector “release” (receiver As Ptr)
release(Ptr(Handle))[/quote]
This sounds unrelated, so you should file a bug report with an example project.
I too think this is unrelated. During development from time to time I go through the RuntimeObject collection before quitting the application to see if there are objects lingering around. If everything is released properly there should be less than ten objects plus the menu items.
During such a check years ago (still RB) I noticed that sometimes when a window is complex and contains PagePanels (or TabPanels) plus ContainerControls, the window is never released. Somehow the “closing cascade” didn’t work and some control on a container on a page panel on a container (or similar) never were closed (the implemented close event was not called). Therefore since then I have implemented in all my container, page panel and also canvas subclasses meaning in everything which can become some sort of parent the Close event and in there I call the Close method on all children.
