How Do Scripts Work？ A script communicates with its host and other applications through a COM technology called Automation （formerly OLE Automation）。 To support Automation， an application requires an object model that exposes certain objects， with their properties and methods， to external applications. An application that supports Automation is called an Automation Server. An Automation server makes its objects available. An Automation Client can manipulate the Automation Server’s objects. With Automation， these applications and their components become objects you can control programmatically. In addition to manipulating objects exposed by the scripting host， a script can also manipulate objects served by other Automation servers. For example， a script in the application can manipulate an Excel spreadsheet or a Word document. The reverse of this is also possible： a Word or Excel script can manipulate a PCB design. Distributing Scripts and Forms You can centrally distribute and update scripts and forms. When you specify a form or script to run on startup， the file’s pathname is stored in a file named scripts.ini. By making this a shared directory pointed to by each user’s WDIR environment variable， groups of users can run the same forms and scripts when an application starts up. For example， some applications will try to run each script/form in every scripts.ini file that they find. They use all scripts.ini files that they find in the project directory and every directory in WDIR. The application must be specified for the AutoActive tools.