We use this code in an internal Installer builder app to ensure a stack
is actually removed from memory:
command removeStackFromMemory pStackName
set wholeMatches to true
repeat while pStackName is among the lines of
revLoadedStacks(application)
set cursor to busy
set the destroyStack of stack pStackName to true
set the cantDelete of stack pStackName to false
lock messages
close stack pStackName
delete stack pStackName
unlock messages
wait 0.5 second with messages
end repeat
set cursor to arrow
end removeStackFromMemory
NOTE: The lock messages ensures that no closeSTack or deleteStack or
related messages get processed when removing the stack from memory. The
wait is necessary as it takes the engine some time to actually remove
the stack, but it will do so - eventually ;-)
I do not claim this is the most efficient way nor the fastest, only that
it works.
On 3/21/2022 2:29 PM, J. Landman Gay via use-livecode wrote:
I've seen this occasionally, where the mainstack is removed but the
substacks are still in the list of available stacks. I think the IDE
list of stacks in memory isn't updated correctly unless all substacks
are marked as destroyed. At least, that's what it looks like.
On 3/21/22 6:46 AM, Klaus major-k via use-livecode wrote:
Hi all,
I have a stack with its destroystack/destroywindow
properties set to true.
When I close it and open another stack which has a
substack with ther same name as a substack of the
previous stack, I get this really annoying dialog:
"A stack with that name is already in memory..."
Shouldn't setting destroystack/destroywindow prevent this?
Or am I misunderstanding the meaning of these props?
_______________________________________________
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
