Stacks not removed from memory?
bobsneidar at iotecdigital.com
Sat May 15 10:56:43 EDT 2021
This issue is so pervasive that I ended up converting all of my relative references to absolute ones. I wrote two handlers, getParentCard and getParentStack, so when I need absolute references I put getParentCard() into tParentCard and then use of tParentCard after any object I need to absolutely reference. I NEVER use this stack anymore.
I agree that when a handler refers to this stack, it should ALWAYS refer to the stack the script object belongs to.
> On May 14, 2021, at 12:49 PM, Marty Knapp via use-livecode <use-livecode at lists.runrev.com> wrote:
> When you close a stack that has its destroyStack set to true, it should not remain in memory. In my case it also seems to get stuck as the default stack. Even if my preference stack did not remove from memory as it should, specifically going to stack "XYZ" and setting it as the defaultStack, one would expect "this stack" to be be "XYZ" but it is not.
> As mentioned I am now querying revLoadedStacks and manually deleting from memory the preference stack and that seems to have taken care of it. But it makes me nervous that the same issue may unexpectedly arise elsewhere in my code. This is an app that has been working fine for years and this has not been an issue till now.
>> On May 14, 2021, at 12:35 PM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
>> Thanks, Marty.
>> I used to use stacks for preferences, but I found arrays to be simpler in addition to being slightly faster.
>> But it seems the core of your issue isn't so much about LC's cache management as with object referencing with "this" - do I understand the issue correctly?
>> Richard Gaskin
>> Fourth World Systems
>>> In my case it's not a name conflict. Lets say I have a main stack "XYZ" and then I query a separate Preference stack:
>>> put the cpCustomProperty of stack "full_path_to_pref_stack" into tPref
>>> close stack "pref_stack"
>>> (my preference stack has destroyStack set to true)
>>> Now thinking that I'm back in my main stack "XYZ" I do something like:
>>> put tPref into fld "123" of this stack
>>> This worked fine for me for years. In LC 9.6.2 rc 5, it would fail most of the time. Curious, I inserted code to find out what LC thought was "this stack" only to discover that *sometimes* it's the preference stack that I just closed.
>>> Then after closing the preference stack, I tried "go stack "XYZ" and "set the default stack to "XYZ" But "this stack" would still (most of the time) report my supposedly closed preference stack.
>>> So now I'm having to query for revLoadedStacks and if my preference stack is listed then I delete it from memory.
>>> I did file a bug report (#23194 ) but as it does not always happen I have not provided a test stack.
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode