Looking for tips on memory mgt in standalones
andrew at ctech.me
Thu Dec 6 17:47:51 CST 2012
So If I duplicate a stack for a "document", and I tell it 'close this
stack'. It doesn't actually remove the stack that was closed from
memory? Whoa, I'm in for some refactoring if that's the case.
stacks that are "destroyed",can they be opened again simply by calling
the stack name a-la : go stack "stackName" (as I often do when I have
closed a stack but want it in memory) or do I have to give it the path
to the stackfile on disk? If so, whats the point of ever setting
destroyStack to false?
On Thu, Dec 6, 2012 at 2:40 PM, Robert Sneidar <slylabs13 at me.com> wrote:
> set the destroyStack property of the "document" stack to true before closing it. Don't worry, the stack file will not *actually* be destroyed. It's a bad name for the property. It should be called "purgeStack" imho.
> Preferences are trickier. You will need to know which platform you are running in, and then you will need to determine the proper place to put preference files for that platform. Search the archives for lots of good info on how to do that.
> On Dec 6, 2012, at 10:16 AM, tbodine wrote:
>> Hi, all. Two questions about standalones...
>> I'm building a desktop app as a standalone that will use separate stacks to
>> store the user's work. A "New File" button creates the stack under a new
>> name and saves it to the user's document area. When the user closes such a
>> file, it looks like it still persists in memory. (Going by what the
>> Application Browser shows.) What's the best way to remove these document
>> stacks from memory in a standalone?
>> Also, the app will need to save user's preferences. Knowing that main stacks
>> cannot save to themselves, I set it up with a substack that stores prefs in
>> custom properties. However, I see now that the substack is actually part of
>> the main stack file. So doesn't that means the substack will have the same
>> problem of being sandboxed by the OS and unable to save? What solutions do
>> you recommend?
>> Many thanks.
>> Tom Bodine
>> View this message in context: http://runtime-revolution.278305.n4.nabble.com/Looking-for-tips-on-memory-mgt-in-standalones-tp4657895.html
>> Sent from the Revolution - User mailing list archive at Nabble.com.
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
andrew at ctech.me
More information about the use-livecode