[Closed] Accessing MacroScript locals from global scope
Hi guys, I got a quite strange question, it could be very stupid, I cannot tell.
macroScript macroTest category:"_MacroTest"
(
local sMacroQuestion = "The Question"
rollout rolTest
(
local iRolloutAnswer = 42
)
)
To access variable iRolloutAnswer from global scope the rollout can be defined as global variable:
global rolTest
Then from global scope iRollAnswer can be accessed with:
rolTest.iRollAnswer
But how to access sMacroQuestion from global scope? Defining a global variable for macroScript has no effect. Is there a way to do this?
Behind the scenes, I need to add a callback from a rollout defined inside the macroScript, calling a function and common variables defined at macroScript level. To define a callback a “global path” seems to be mandatory, how do I get it? (Please don’t tell me to move everything in the rollout, or in a global struct, the design is a little more complex than this). Thanks.
- Enrico
to get access to a variable in a macro from other script you have to declare this variable as global both in the macro and in the script…
Thanks Denis, but I even hate to hear the word “global”
The solution I’m thinking about, is to define common variables and functions at MacroScript level, so they’re accessible from every nested rollout without further specification, then create a “hidden” rollout (read without user interface elements) local to MacroScript as recipient, where only common function needed for callback are aliased, then the callback is initialized somewhere else by fully specifying the hidden rollout path. The only global variable is the hidden rollout, set to undefined as soon as the script ends.
I’m still open and on time for other solutions.
- Enrico
“hidden rollout” sounds worse for me. You can use a structure. It will be only one global pointer.
Well, it’s not that bad, it’s a simple placeholder and automatically reads outer (MacroScript’s) scope. If I have to define a Struct, it should hold full function definitions and not aliases, and when I need to reach them from its instance, everywhere and not for callbacks only, there’s a step more in the path. I hate having to type (intellisense I miss you so bad), and keep in line, a path made of 4 steps because of nested Structs. Currently I need at least 3 levels here and there to keep code way more rational and clean. Anyway, I’ll give Struct a twist. Sometimes simple solutions are hard to find, and simply pop in your mind as you’re writing code. Thanks.
- Enrico
Here is a simple scheme of current script design. It’s actually a bit more complex as it defines more rollouts loaded into a subrollout in rolMain, but that’s quite simple and would only clutter the scheme. Must be said, because every other rollout needs to access common variables and functions, that in this case were defined in macroscript scope to be accessible without further specification and remain local to the script.
macroScript macroTest category:"_MacroTest"
(
local theObj = undefined
function getTheObj =
(
theObj = selection[1]
format "The first Object selected is: %
" theObj
)
---------------------------------------------------------------------
global rolCallBacks
rollout rolCallBacks
(
function _getTheObj = getTheObj()
)
---------------------------------------------------------------------
rollout rolMain
(
-- ROLLOUT USER INTERFACE, FUNCTIONS AND SO ON, HERE
-- From here theObj is accessed without further specification.
-- If it was defined into a global Struct it would require
-- the instance name specifiaction too.
on rolMain open do
(
callbacks.addScript #selectionSetChanged "rolCallBacks._getTheObj()" id:#cbTest
)
on rolMain close do
(
callbacks.removeScripts id:#cbTest
rolCallBacks = undefined
gc light:true
)
)
---------------------------------------------------------------------
on execute do
(
try ( destroyDialog rolMain ) catch ()
createDialog rolMain
-- rolMain actually doesn't have a User Interface
-- but it's ment to have it
)
) -- End macroTest
- Enrico
I don’t understand why is a global pointer to rollout better then a pointer to function or structure?
and what’s wrong with this:
macroScript macroTest category:"_MacroTest"
(
---------------------------------------------------------------------
global rolMain
rollout rolMain ""
(
-- ROLLOUT USER INTERFACE, FUNCTIONS AND SO ON, HERE
local theObj
function getTheObj =
(
theObj = selection[1]
format "The first Object selected is: %
" theObj
)
on rolMain open do
(
callbacks.addScript #selectionSetChanged "rolMain.getTheObj()" id:#cbTest
)
on rolMain close do
(
callbacks.removeScripts id:#cbTest
rolCallBacks = undefined
gc light:true
)
)
---------------------------------------------------------------------
on execute do
(
try ( destroyDialog rolMain ) catch ()
createDialog rolMain width:200 height:100
)
) -- End macroTest
why do you need another (“hidden”) rollout?
Well, I got a macroscript with several rollouts all defined into the macroscript scope level. Main and other four (right now) added to a subrollout in Main. All these rollouts need to access a bunch of common variables and functions. Variables and functions defined at macroscript scope level are visible to every rollout without adding anything else to their name. If I define those commons in a rollout, as you did in Main, every time I must to access them from another rollout I need to fully specify the path, like mainRollout.commonVariable which is quite tedious and clutters the code. That’s why commons are at macroscript level.
Since some of those common functions need to be added to callback calls when the script initializes (read when Main rollout is opened) I need a full path accessible by global scope. Variables and functions defined at MacroScript scope level are called “private globals” (from MaxScript reference) as they are global to the whole script but invisible outside of it unless explicitly defined as global. So I create a rollout without any user interface as a recipient for those common functions to add as callbacks, and simply create their alias, and use that one in Main rollout to trigger the callback. The hidden rollout is the only thing that must be declared as global in order to let the callback work.
After some experiments I found out structures can handle aliases, so I can define commons in MacroScript, create a struct with aliased functions, create a global instance and use that for callbacks, exactly the same as “hidden rollout”. I guess I’ll go for this solution.
If I had to create a structure with full common function definitions and variables, I’d need to add structure instance name to the path whenever they where called from every rollout, again, quite annoying and unnecessary, like structName.commonFunction.
That’s it. I hope it makes some sense. I’m not an English native speaker
don’t think this is a solution but how about using a ini file or xml (from what i know xml is faster then ini )…
-Remus