Hi all,
I am reworking the architecture of the tools I am working on.
For modularity’s sake, and to keep all the various scripts compartmentalized, each rollout generally goes in its own .ms file with the functions and handlers specific to that rollout.
I have one “main” rollout from which I launch the others that are needed.
I am also trying to keep my “library” of scripts as organized and elegantly executed as possible. What I’ve unfortunately had to resort to, though, is doing a “fileIn ‘otherscript.ms” at the top of my main script for every rollout I want to launch, in order to “forward declare” their functions I guess.
For example, what I’d LIKE to do is only fileIn a script exactly when I need it, so it’s not automatically executed at the start of the main script, so:
Mainscript.ms:
rollout someRollout "Some rollout"
(
button someButton "Launch other script"
on someButton pressed do
(
fileIn "otherscript.ms"
launchOtherUI() --located in otherscript.ms
)
)
This doesn’t work. Even though I just fileIn’d the other script, launchOtherUI() is still undefined.
What works:
fileIn "otherscript.ms"
rollout someRollout "Some rollout"
(
button someButton "Launch other script"
on someButton pressed do
(
launchOtherUI() --located in otherscript.ms
)
)
…which works. But, in my opinion, is not the most elegant solution since now for EVERY one of my external scripts that I want to launch, I have to fileIn them at the very start, which to me just says “bad design”.
So cgsociety, please let me know what you think is a good architecture for having multiple scripts with their own rollouts, and launching them from each other!
launchOtherUI is some global function, right?
try:
global launchOtherUI
rollout someRollout "Some rollout"
(
button someButton "Launch other script"
on someButton pressed do
(
fileIn "otherscript.ms"
if launchOtherUI != undefined do launchOtherUI()
)
)
or:
rollout someRollout "Some rollout"
(
button someButton "Launch other script"
on someButton pressed do
(
fileIn "otherscript.ms"
if globalvars.isGlobal #launchOtherUI do launchOtherUI()
)
)
What you see is basically a scope issue, at the time the script is parsed, there’s no known launchOtherUI variable declared and so it’s created as a local in the event handler scope. To fix it, it’s enough to change it to ::launchOtherUI() (and possibly test if ::launchOtherUI != undefined else do the fileIn.
but honestly i’m not sure that your concept to put all rollouts in their individual files is a good idea.
Thanks guys for the replies! Good suggestions all around. It seems checking if the function is undefined first is a good idea.
denisT – Yes I’ve noticed in other people’s maxscript tools that they generally put everything into one huge .ms
Coming from a computer science background it’s only been natural for me to want to separate everything out in a faux-OOP manner.
This actually leads to something I’ve been struggling with and pondering a lot since becoming a TA and working with maxscript… what are some optimal architectures for large maxscript projects?
I am currently:
- creating a modular library of utility scripts (file name parsing, XML I/O, etc) that through either include() or fileIn() I can use as needed, and
- Separating the different rollouts/tools into separate scripts so they can be maintained independently, version controlled separately, and also called only as needed.
I’ve actually seen/read very little on mxs tool architecture, abstracting out functions and scripts so they can be re-used across multiple projects, script modularity, etc.
I’d love to get everyone’s thoughts on this and get a discussion going, some do’s and don’ts, and maybe even eventually get some kind of documentation or guides written up!
i’m from a computer science background too, and use logically closed code modules in separate files in c# or c++ projects. but MXS is different. Sooner or later you will have tons of ms, and mcr files in different places which you will not be able to manage.
My concept is:
if the tool is a dialog with multiple rollouts it has to be one file
if the tool has only one rollout it might be a separate file
if some tools work in the same area (poly tools for example) they have to be in one file
all common used functions should be grouped in separate files (window ops, control ops, mouse ops, callback ops, math ops, viewport ops, etc.)
all macroscripts of the same sub-category has to be in one file…
I don’t like to use “filein” in MS files and do it very rarely.
and I never use “include”.