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
