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 rdim...@evergreeninfo.net -----Original Message----- From: use-livecode [mailto:use-livecode-boun...@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@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 > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > use-livecode@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
