Stacks not removed from memory?
curry at pair.com
Fri May 14 21:33:39 EDT 2021
> 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.
Which way is better? I'd say #1 is superior. That's my ideal too.
Truly fixing it is much better than putting on a field dressing.
What's the caveat? New LC code is usually buggy and glitchy.
Some issues are solved quickly, others take many years, or never.
Thus, unfortunately "#1" versus "#2" might not a real choice.
Actual choice, if quality is desired: "#2" versus "#1 PLUS #2."
It shouldn't work that way, but unfortunately it has, so far.
Anyway, good idea! I would be happy if LC does either. Just do it well.
Besides the more obvious name conflict issues, we also have SE sometimes
becoming dis-associated from the control whose script is being edited.
That one is pretty fun to keep people on their toes while coding!
Also, it's pretty crazy when standalone mishaps embed LC stacks in user
stacks, and then the IDE makes it a little bit more difficult to remove
the offending substacks due to the name conflicts.
Similar: With certain project organization habits, it can add to the
mayhem when name conflicts join the new messages-on Standalone Builder
dance. Purge dialogs galore! Easy enough to work around, but a robust SB
process that doesn't conflict with itself would be a big boost for LC.
> 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.
"This" habit? Which habit was that? (J/K) :)
Thanks for promoting this solution.
Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
More information about the use-livecode