Stacks not removed from memory?
ambassador at fourthworld.com
Fri May 14 15:35:23 EDT 2021
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
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.
More information about the use-livecode