View Full Version : global vs non-global proc

10 October 2005, 11:10 PM
hello everyone,
i've got a pretty simple script going on here that i have a question about:

it consists of 3 procedures, the 1st is a global proc to build the window. 2nd and 3rd proc are non-global. the 2nd proc just changes status of a button in the window (toggle on / off). 3rd proc is actual functionality of the script (toggles visibility of nurbs curves controllers in current panel).

when i copy paste the script into my script editor and enter it all in, it works great. but if i start maya up fresh and source the script and run it, the script can't call the non-global procs (but it builds the window just fine). my questions are:

first, what is the difference between entering it all in through the script editor and sourcing.. obviously it retains all the procedures in memory but i don't know why source is different than opening the script.

second, should i make all of the proedures global so the script works all the time? i'm a little wary to just do that, because i know using all global proc's all the time is a bad idea (even though for a small script like this it probably wouldn't matter). if using global proc's is a bad idea, what's the correct workaround so that i can have my script work without using global procedures?

thanks everyone for your help...

10 October 2005, 11:17 PM
Making those proc's global is not a "workaround" is what you are intended to do.
The proc you have to handle the status of the UI definitely has to be global. If you have a proc which gets called when you press a button or something then that has to be global as well. If that proc calls other proc's inside the same file to do what it needs to do then you can leave those non-global.

10 October 2005, 11:28 PM
so it kinda sounds like even though all of the proc's were in the same physical location (same .mel file), they aren't actually all being loaded at the same time, right? the window is built and then the procedures that the window requires for use aren't necessarily loaded at the same time? considering the one procedure changed the status of the button and the other one was the actual functionality of the button (i.e. both of them were related to the button), i changed them both to global and now everything works just peachy. thanks leafs (go pens!)

10 October 2005, 02:30 PM
Well, the non-global procs are "loaded" in that they can be called from within other procs withing that file. But when you call a proc from a button press it's not getting called from within that file...even though that's where you specified the call.

Also, executing stuff from the ScriptEditor is a little bit different. Things that are executed there are considered global unless you wrap it in { }.

And one last thing...GoPens??? Before the season all the "experts" predicted that the Pens would finish ahead of the Leafs but...have they even won a game yet? :)

10 October 2005, 06:10 PM
i'm a little wary to just do that, because i know using all global proc's all the time is a bad idea (even though for a small script like this it probably wouldn't matter).]
I wouldn’t worry about that to much. You just have to obey to some simple, clean code practices to avoid problems. Same goes with global variables. The main thing to consider is to give your global vars descriptive, easy distinguishable and memorable names.
Personally I have precede them with my initials and then use a descriptive name like kmGetDistanceBteweenParticles.
This might give a shudder to hardcore coders, but it makes debugging a whole lot easier, especially when you write longer scripts and when your procs are referred to in other scripts, written by other people.
Unless you are working with literally thousands of your own procs, I wouldn’t worry to much about the memory issues people often associate with global procs/vars.

CGTalk Moderation
10 October 2005, 06:11 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.