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. Bob S > On May 14, 2021, at 12:49 PM, Marty Knapp via use-livecode > <use-livecode@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. > > Marty > >> On May 14, 2021, at 12:35 PM, Richard Gaskin via use-livecode >> <use-livecode@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. >>> Marty >> > > > _______________________________________________ > 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
