CGTalk - Talking to other scripts>?

Bobo

10-23-2006, 05:36 PM

Is there a help topic that talks about using two different script files, one for UI and the other for the functionality? I want to have the ui set variables and pass them back to the other. Or is it best to avoid that and keep it in one script?

also the topic on the function lib scripts i don't quite get the usage what i always end up with is setting a variable and then calling the function which doesn't give me the result until I evaluate the script with the functions in it. Which sounds sloppy. :(

Thanks for any help :cool:

-BakerCo

The trouble with having split functions and UI is making sure both are evaluated in the right order and updated when needed.
The solution is to place the functions part of the script in the Stdplugs/StdScripts folder so it gets evaluated early on in the booting process, and keep the UI in the UI/Macroscripts folder so it comes in later.

In the functions file, it is a good idea to declare a variable as global and define a structure with the same name containing all functions needed. This way, you would pollute the global scope only minimally and have a nice container of all functionality needed by your script.

On a script I am developing for Frantic Films' Deadline (the Max to Deadline submission script shipping with version 2.5 and higher), I used exactly this approach. The main difference is that both the functions and the UI Macro reside in the network repository on a remote machine and both are being evaluated by a loader script which pulls the sources from the server and calls fileIn() on them to make sure each workstation is always using the latest version of both files. This way, I can update the sources on the network and any user hitting the Macro button in the UI on his workstation will force an update each time he runs the script...

In addition, all the data needed for the functions is stored in yet another global strucure (this one without any functions in it, and you have to create an instance of the structure to be able to access its properties). All the properties in the structure are initialized to defaults and can be updated from an INI file by the functions doing the actual work. This way, it is possible to call any of the functions in the functions structure from the Listener or any other 3rd party script without ever running the UI portion of the script.

The latest version of the script goes a step further. To make the script run on both Max 5-8 and 9, the UI part was split into multiple blocks which get Include()d to build the final UI code. There are two main UI files - one for Max 5-8 and one for 9, with the blocks containing ActiveX controls replaced with DotNet versions of the same code for the 9 version. When the updater is run on the local workstation, it checks the Max version and pulls the version of the script from the network matching the Max installation, thus automatically replacing ActiveX with DotNet controls... To make sure the paths are resolved correctly, the portions of the UI code are first copied to the local \Scripts folder using copyFile(), then the main script is run using fileIn() and its include() calls resolve the names of the other .MS files easily. In addition, it is much faster to copy first and evaluate locally than to evaluate directly from the network...

I don't think there are good examples in the MAXScript Reference regarding such approaches, but all the building blocks to get your code organized are in there - Include(), fileIn(), struct etc.