Hi David,
It is just good practice to set unused objects to nothing, but all classes
have a destroy method when closed and discarded, and usually but not always
erase all objects from memory.
So, in 99% of all apps and such when shut down all variables and objects
are removed from the namespace. The reason for shutting down an app and
restarting, for all those objects get initialized again.
So, you can look at almost all apps and go down to the creatdialot event
and you will find in that setion and beneath it the init of all objects and
destruction of them if the dialog is closing. That is where you do all of this
by monitoiring the events that are created by the type of thing you are doing
that uses a call back feature.
But look at the class structure and read up on what is needed and where.
Bruce
Sent: Friday, June 15, 2012 7:06 PM
Subject: OnQuit
When connecting to the OnQuit Event, I do understand I can create a sub,
named things like OnQuit. Here, I could do a bit of house cleaning for my app.
But from what I can read in the Reference manual, it seems this event only does
fire when WE as a total is closing down. Am I understanding it correct?
If so, is there a way for me to do house cleaning, even if a user turns off
the app itself, but keeps WE running? Any Event that fires, when an app is
stopped or being disabled?
Another techie thing:
Say my app is using 10Kb of memory for different objects and stuff. I try to
be in a habit of always setting objects that are not in use to NOTHING. But
imagine my app being poorly designed, not doing this kind of nullifying. If now
the user stop the app - in the app manager - and then restart the app. Will the
app be using the SAME physical 10kb of memory, or will it create allocations
for new 10kb? I.e, if the app is stopped and restarted 100 times, will it still
only allocate the same memory, or will there be a risk of memory usage building
up? Hope this makes sense.
