On 5/15/21 9:56 AM, Bob Sneidar via use-livecode wrote:
I agree that when a handler refers to this stack, it should ALWAYS refer to the
stack the script object belongs to.
That would be a catasrophe when the handler is in a library or a backscript. I use "this stack"
in those. It would be
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
Richard:
> Because if it's just the stack name conflict thang,
> I'd rather we solve that at the root by being done
> with that IDE-imposed limitation
Yes, good idea. I would be happy if LC either:
1. Solves it at the root, per RG suggestion.
2. Fixes what they already have, in the IDE.
On 5/14/21 2:49 PM, Marty Knapp via use-livecode 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
Thanks.
So many things can legitimately change the value of "this" I generally
prefer more explicit references.
Maybe with this apparent bug there's one more reason I'm grateful to
have adopted this habit.
--
Richard Gaskin
Fourth World Systems
When you close a stack that has its
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,
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?
--
It’s happening for me in standalone. And I should mention that my tests were on
Mac only (Mojave).
Marty
> On May 14, 2021, at 10:59 AM, Niggemann, Bernd via use-livecode
> wrote:
>
> If the Project Browser is open then it may be related to
>
>
If the Project Browser is open then it may be related to
https://quality.livecode.com/show_bug.cgi?id=22460
Kind regards
Bern
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
On 5/14/21 10:05 AM, Richard Gaskin via use-livecode wrote:
Is this to avoid stack name conflicts, or is there some other reason to
use this feature?
Because if it's just the stack name conflict thang, I'd rather we solve
that at the root by being done with that IDE-imposed limitation that
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
Devin Asay wrote:
> I have seen what you’re describing on all of the recent releases—9.5 -
> 9.6.x; i.e., a stack with destroyStack set to true, then closed, is
> not always removed from memory. Sometimes this has caused an infinite
> loop with the Save - Purge - Cancel dialog. I would report
Marty,
I had intended to respond to this, but got busy with other things.
I have seen what you’re describing on all of the recent releases—9.5 - 9.6.x;
i.e., a stack with destroyStack set to true, then closed, is not always removed
from memory. Sometimes this has caused an infinite loop with
13 matches
Mail list logo
