Maxscript: RolloutCreator Memory Leak?

SimonT

Hi Guys! I just read about garbage collection and it seems "OK" that maxscript reserves more and more memory with every script-run. BUT i wondered why this small scripts counts the rollout numbers up and up...

Script:

(
	rci = rolloutCreator thename "test title"
	rci.begin()
	rci.end();
	
	print rci.def
)

Ouput after 1st run:

Rollout:rolloutCreator1

Output after 2nd run:

Rollout:rolloutCreator[B][COLOR="DarkOrange"]2[/COLOR][/B]

...these rollouts are created in a local scope and so i would expect that after the script is done, max doesn't know that the rollout ever existed. But it does. Yes the first argument is a variable which doesn't exist, but anyway, i wonder why the script output counts up and up. I hope this isn't some kind of memory leak where every rollout stays in memory until a max restart. Even a gc() doesn't "reset" the numbers which the rollouts get.

Bryan Cavett

Seems like you're missing quotes around the rollout name, which you already knew about. Im guessing its not seeing that variable though since that's the same output i'm getting on my end when i don't have the variable defined. Once i gave it a string it stopped appending the numbers to the definition output.

rci = rolloutCreator "myRollout" "My Rollout"

Ive never used the rolloutcreator struct before. I usually use "createDialog" and "destroyDialog" and assign my rollout to a global variable so I can test to see if its already open and then destroy it so I don't create a second window when the script is ran again.
Like this:

macroScript Macro3
category:"DragAndDrop"
toolTip:""
(
    global BCT_someDialog
    rollout BCT_someDialog "someDialog title" width:200 height:100
    (
        button btn_Cancel "Close Dialog" width:150 height:30
        
        on btn_Cancel pressed do
        (
            if BCT_someDialog != undefined then destroyDialog BCT_someDialog
        )
    )
    
    if BCT_someDialog != undefined then destroyDialog BCT_someDialog
    createDialog BCT_someDialog 200 100 lockHeight:true lockWidth:true
)

Swordslayer

When in doubt, just look inside rolloutCreator.ms, it's just a global struct and when the rollout name is undefined, it increments the counter and creates a new one. Anyway, it executes the final string in global scope (yeah, that's all it does, concatenates a bunch of strings and tries to execute that), it is NOT created in local scope.

SimonT

Bryan Cavett
Yeah i was just afraid that maybe it creates several instances under the same name when using a string. Thanks for your examples! I normally do it like you said but this time i need a dynamically created UI which makes me use the rolloutCreature function.

Swordslayer
That's weird. Because when i try to access "rci" i just get "undefined" back. Only when i delete the ( and ) and make the whole script to global scope, i can access "rci" after i executed the script.

Swordslayer

Sure, the rci variable holding rolloutCreator instance stays in the local scope - but that's not what I'm talking about, have you looked inside the script? The rolloutCreator cobbles together the pieces of string you give it and finally calls execute on the resulting string - and of course, execute ONLY works in global scope, the rollout that is created is created in global scope, which also means that when its name is the same, it overwrites the previous rollout definition of that name. That's the reason there's a global __rcCounter variable in the rolloutCreator script, which gets incremented every time the user supplies undefined name - to prevent it from accidentaly overwriting some other rollout.

monster

If you ever suspect a memory leak you can always check the memory allocation to MaxScript using heapfree.

(
	rci = rolloutCreator "thename" "test title"
	rci.begin()
	rci.end()
	
 	rci = undefined
	gc()
	print (heapsize - heapfree)
	
	
 	ok
)

The output holds pretty steady for me.

22049780L
OK
22049788L
OK
22049780L
OK
22049788L
OK

SimonT

Swordslayer
Ah ok now it's more clear to me, thank you for your answer!

monster
Oh cool thank you! Didn't know that!