Notifications
Clear all

[Closed] Removing variables from memory?

Hi there! I’m in the process of learning MAXScript, and when debugging scripts I realize that I have some problems with the scope of variables. Because of this, one script cannot work the first or the second time I run it, but the third and the next ones it works… So in order to avoid this and to help me to fix the problem, I usually exit MAX for ‘flushing’ all the variables stored in memory, and run the program again. Reseting MAX does not seem remove the variables stored in memory.

So is there any function for removing all the stored variables from the memory? Or is the only way quitting and re-launching the program?

Thanks!!!

11 Replies

Garbage Collection might do it?

Gc()

Hi, Dave, and thanks for your fast answer! And nope, I tried gc() before and it does not seem to erase the declared variables. One solution might be declare only local variables (I know I should go that way)… but for trying stuff usually I go from the general thing to some particular details (as everyone does). I’m a very rough boy

Swami Lama wrote a script to do this a while back (search scriptspot.com) but it’s not really the way to go. You really need to get a handle on scope as soon as possible!

I’m sure if you ask in the forum with specific scope-related questions, people will be happy to help out.

One solution might be declare only local variables (I know I should go that way).

Yeah – in 95% of cases, you should always put “local” in front of variable declarations! Locals can only be declared within code “blocks”, so make sure your entire script is wrapped in brackets (this happens automatically if you’re building code in a rollout, or macroscript)

Programming seems like lots of needless typing when you first start, but after a while you get used to it and it doesn’t bother you any more.

To be honest, once you start doing thinigs right, and stop having to restart max all the time, you’ll be GLAD to be typing “local” a lot. “Yippee! Another local variable!!” you’ll shout… no REALLY, you will

Something I got in the habit of doing is to put the whole code in its own scope. For example, if I do:

 
(
	a = 1
)

Evaluate the whole code, then go in the listener and evaluate ‘a’, it’ll read undefined instead of 1.

Thanks, Dave! I had a very specific problem on one script. It has this structure…

fancy rollout
  (
   function
  (
   do nice things and use some variables that are stated below this function
  )
             
    on button pressed do
      (
       here comes the variable I was talking before
      )
   )

… and, obviously, using local variables inside the “on button pressed” chunk doesn’t make the variables usable on the functions. I tried to declare them as local before the function, but the program does not seem to work. But declaring them as global variables in the same plance (ow, danger, danger!) makes the script work from the first run. I thought that declaring at top-level makes the variables usable by the rest of ‘nested’ scopes, but maybe there’s still something I missed…

Jason, thanks! That’s an easy and nice way to go

One way to do this is to add the variable as in input to the function. Example,

fn doSomething myVar =
(
returnVal = myVar * 2
return returnVal
)

on myButton pressed do
(
Var = 2
retVal = doSomething Var
)
myVar is an input for the function and can be used to pass variables to the function. Writing the function this way you can pass the variable directly to it, the function doesn’t need to “know” what the variable is before hand. You can have as many inputs as you like. Hope this helps.

-bnvm

Use structs. It helps managing your variables

Rollouts are similar to structures, but you can get inside them by just using the rollout name as a “class” reference… Local vars inside can be utilized from the outside this way…


 (
 rollout FancyRollout "Fancy"
 	(
 	local VarInRollout = 4
 
 	button but_Press "Press Me"
 	
 	fn Dosomething =
 		 ( format "something
")
 		 
 	on but_Press pressed do 
 		(
 		Dosomething()
 		)
 	)
 CreateDialog FancyRollout 100 40
 
 -- Show value found INSIDE rollout.
 format "VarInRollout = %
" FancyRollout.VarInRollout
 -- Do function INSIDE rollout
 FancyRollout.Dosomething()
 )
 

Yippee! Another local variable!!

1 Reply
(@davestewart)
Joined: 10 months ago

Posts: 0

Hilarious!

In this case, you can what’s called “pre-declaring” a variable. Essentially, you just declare its name, then later on in the script you write the variable / function properly:


 
 local fnTwo -- this variable has been "pre-declared"
 
 function fnOne =
 (
 fnTwo()
 )
 
 function fnTwo =
 (
 print "fnTwo called!"
 )
 
 fnOne()
 

This way, the first function “knows” about the second one, so you don’t need to polute the global scope with tons of variables. Most languages don’t require you to do this (but most languages don’t do cool 3D stuff like MXS does, so we’ll forgive it, just this once ;))

The best thing to do is to declare as many variables as you can at the start of the script. I lay my scripts out like so:


 -- interface
 -- variables & structs
 -- functions
 -- handlers
 

As labbejason said, you don’t always need to use the “local” keyword when in block scope, but I always do as a matter of tidiness. When I see a block of declarations using local (I think max color-codes them blue) it’s just really easy to see that you’re setting up a bunch of stuff.

Half of programming is actually about being organised. If you can read the code quickly and easily, it leaves more of your brain free to think about the harder stuff, like matrices, trig, maths, verts… you get the idea!

Hope that helps.

Dave

Page 1 / 2