Go in Window on Mobile / Not Obeying Purge?

Ralph DiMola rdimola at evergreeninfo.net
Fri Mar 1 14:43:04 EST 2019


That's one of my annoyances. Say you are inspecting a field and then delete the field the inspector does not close. One would think that if a control is deleted while an inspector for that object is open the inspector would close. This makes me wonder if the card retains some artifacts of the deleted field if it's deleted while the inspector is open?

Ralph DiMola
IT Director
Evergreen Information Services
rdimola at evergreeninfo.net

-----Original Message-----
From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Peter Bogdanoff via use-livecode
Sent: Friday, March 01, 2019 2:10 PM
To: How to use LiveCode
Cc: Peter Bogdanoff
Subject: Re: Go in Window on Mobile / Not Obeying Purge?

I’ve found that if an inspector is open for something in that stack, purging is incomplete.

Peter

> On Mar 1, 2019, at 7:37 AM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Sannyasin Brahmanathaswami wrote:
> 
> >... although all my modules/stacks have both "purge stack/window" set  
> >to true, I am seeing change on stacks that are  "closed" when you  
> >reopen them again.
> >
> > Thus, it means that Purge stack/window  is not implemented on
> >
> > Go [new-stack] in window of stack [old-stack] on mobile.
> >
> > Can anyone confirm? I wonder how long the RAM can keep up before it 
> > crashes.
> 
> Personally that seems like a bug to me.  Maybe worth reporting.  The manner in which a stack is closed shouldn't matter with regard to how destroyStack works.
> 
> But just to clarify, the stack in question is a separate stack file, and not a substack of the one you're going to, yes?
> 
> Remember that LC keeps the entire stack file in RAM, and can't purge it until the mainstack and all substacks within the stack file are closed.
> 
> If it is purgeable (as a separate stack file), my hunch is you won't ever see a RAM issue from caching.  If you do it would be a bug. Caching is intended to speed up access, not to prevent ordinary behavior, so things not in use are purged as RAM is needed (same with cached images and other things).
> 
> If you're seeing slow or crashing behavior that seems like it might be RAM-related, maybe Apple's Instruments tool in xCode can help provide clarity on that:
> https://apple.stackexchange.com/questions/71237/how-to-identify-cpu-an
> d-memory-usage-per-process-on-iphone
> 
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web 
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list