Say I have a script that creates a rollout in a dialog and starts like this:
(
global theRollout
try destroyDialog theRollout catch()
...
So if I run the script a second time while a first instance is active, it will close the first dialog.
Two questions:
- does destroying the dialog actually end the script’s execution?
- does it flush the memory of all the variables used by the first instance?
There’s nothing inside a rollout that’s normally exceuting – except for, say, a timer UI element… closing the dialog/rolloutfloater in which it exists would certainly stop the timer.
The memory is not freed up in this case, however… the rollout – including its local variables – continues to exist. The only thing you’re doing is closing the dialog / rolloutfloater window.
Any memory used up by the UI elements themselves for display, however, is freed up…but this tends to be insignificant.
As I understand it – correct me if I’m wrong – rollouts work only through event handlers.
This makes me wonder… every time I close the dialog and run the script again, do I still have the previous instances of the scipt waiting in the background for an event that will never come? Couldn’t that become a memory issue for scripts that use a large amount of data?
I’ve looked in the reference for an instruction to stop a script’s execution, so I could put it in an on close handler, but couldn’t find it.
I feel like I’m misunderstanding something important here…
Correct. The UI elements just sit there and typically do nothing automatically… except for a timer or any .NET control you might have inserted that has automated events as well.
This makes me wonder… every time I close the dialog and run the script again, do I still have the previous instances of the scipt waiting in the background for an event that will never come?
Yes – although the event may come… that’s why it is kept in memory.
E.g.
rollout test "test" (
button btn_test "test"
on btn_test pressed do ( messageBox "Hello!" )
)
test.btn_test.pressed()
The UI is never opened, but you can still invoke the event handler. The only exception to this, that I know of, is the timer UI control which really only ticks if the dialog is actually open.
However, when you re-run your script… entirely… then re-defining your rollout will replace it entirely. I.e.
rollout test "second test" (
-- etc.
)
Will replace the original ‘test’ to the point of it simply not existing anymore. It may technically be that it does still exist in memory, but there’s nothing pointing to it anymore and it would get cleared at the next garbage collection event.
I’d have to ask what script code is executing that you would want to stop, then, as typically code does not actually run unless you (or, again, a timed element… or a callback… or, etc.) make it run.
Sorry, my last question came out wrong. It’s not about stopping the execution per se but freeing the memory used by the script.
I just read what the reference says about garbage collection. It seems to take care of what was worrying me, though I don’t really understand how it works. I’ll try to find some documentation on the net.
Thanks for your time and patience, Richard. Your explanations are very clear.
Edit: Is it good practice to reset all the arrays to #() in an on close handler?