Stacks not removed from memory?

[Curry Kenworthy]

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.

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.

BUT... (!)

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.

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/