Mega Code Archive

Adding active scripting support to Delphi applications

Title: Adding active scripting support to Delphi applications Question: Why are scripting abilities needed in Delphi applications? There are many possible reasons. - For example, we are developing game. Many actors, many situations. Scripting is the good (and maybe the only flexible enough) way to let users (or addon developers) to: - vary objects and actors properties, reactions, abilities etc.; - add new objects and characters; - create new game scenarios - Text processing applications. Perl is the best langauge to work with texts: search, replace, regular expressions. Perl can do much more then Delphi with texts. So we can mix them and take the best from both of them - why not? Write user interface in Delphi and let script extensions (using Active Perl) to handle texts. - How to create plugin-based application? There are copule of ways: DLLs (or BPLs), COM... Why not scripting? Make some interface to read and execute scripts in application, make specifications and go ahead: application is open to extension using any active scripts: VBScript, JScript, Perl, PHP, Rexx, Tcl... the only requirement is that corresponding active script extension must be installed in windows script host. - Installers are exactly those applications which need scripting abilities... - Any applications which must be managed from outside. For example, some application can consist of the set of all-sufficient objects and scripts loaded from outer storage may trigger any actions, change any parameters, allow/disallow any functionality of apllication objects. - Applications with variable execution sequence. - Etc, etc, etc... Answer: 1. Why scripting? Why are scripting abilities needed in Delphi applications? There are many possible reasons. - For example, we are developing game. Many actors, many situations. Scripting is the good (and maybe the only flexible enough) way to let users (or addon developers) to: - vary objects and actors properties, reactions, abilities etc.; - add new objects and characters; - create new game scenarios - Text processing applications. Perl is the best langauge to work with texts: search, replace, regular expressions. Perl can do much more then Delphi with texts. So we can mix them and take the best from both of them - why not? Write user interface in Delphi and let script extensions (using Active Perl) to handle texts. - How to create plugin-based application? There are copule of ways: DLLs (or BPLs), COM... Why not scripting? Make some interface to read and execute scripts in application, make specifications and go ahead: application is open to extension using any active scripts: VBScript, JScript, Perl, PHP, Rexx, Tcl... the only requirement is that corresponding active script extension must be installed in windows script host. - Installers are exactly those applications which need scripting abilities... - Any applications which must be managed from outside. For example, some application can consist of the set of all-sufficient objects and scripts loaded from outer storage may trigger any actions, change any parameters, allow/disallow any functionality of apllication objects. - Applications with variable execution sequence. - Etc, etc, etc... 2. What exactly is needed? What are the basic requirements to scripting engine mixed with Delphi application, in the most of cases? As practice shows, there is well-defined set of abilities wich scripter "must have", if it pretends to be universal scripting addon for Delphi application: - Support of most known scripting languages. VBScript and JavaScript, Perl, PHP. May be also Python, Tcl, Rexx, Python and other. In other words, any language which is supported by Windows scripting host engine. - Easy to integrate with Delphi application. - Ability to operate with Delphi application objects, their properties, events and methods; deleting and creating objects in script; passing object parameters to script procedures and functions. - Recognizing errors occured during script execution. - Quick and eminently qualified support answering to any questions - they will appear anyway, if you will be seriously engaged in scripting tasks in your applications. - Online help and manual containing all most important questions. - [ ] Add your ideas here. 3. How to get all described above? There are all needed instruments present in Windows and Delphi. They are: - Microsoft script control.This is ActiveX which realizes Windows script host engine. - Delphi RTTI information. By the highest standarts, this is all what we need to know to go ahead with scripting. MSScript ActiveX can run scripts and operate with objects (or rather, their IDispatch interfaces). Objects are added to script control by its AddObject method. The main problem here is, that after object leaves script's namespace, its _Release method is called and object then is destroyed (oh, this annoying Access Violation...). There are 2 ways to resolve this problem. First is implementing every object that has to be operated by script as OLE server. Second is to find some way to create "representative" (or "proxy") object which will translate call to methods and properties of Delphi object from script "on-the-fly". Then this object can be destroyed after script finishing, without deleting of object itself. And RTTI is the thing wich will help us. Second way has a couple of advantages: - No OLE servers, TLB's, registering COM objects etc. We may even don't know COM technology. - Only TAutoObject descendants (which are ole-servers in Delphi) can be added and operated in scripts, if we will use the first way. In the second way, any object descending from TPersistent (in other words, for which Delphi compiler does generate runtime type information) can be handled. So, this open wide perspectives for using all richness of VCL components in scripts. - The only, universal, class can be used to be bufer between Delphi objects and script environment. Instance of this class can handle RTTI of objects, create their proxies and put them into script. - All handling can be performed "on-the-fly", so we don't need to guess: what exactly can be required to be accessible in scripts tomorrow? Or tomorrow after tomorrow? Just register all possible classes in Delphi application (using Classes.RegisterClass procedure) to be sure that compiler will not drop RTTI due to optimization, and, for example, add to scripter main form. Then everything contained by this form will be accessible in script. RTTI is a panacea here. 4. Is there any component meeting these requirements? Exactly! New version (2.0 is up to date on May 19, 2003) of Delphi script component named TekWSHControl (Windows scripting host control for Delphi) from Ekas Software is able to do everything described above, and even more. Visit this scripter component home page and learn more about it. Almost all possible questions are coveraged there, and support will quickly answer the rest if any. 5. What are basic TekWSHControl advantages? - Any script language supported by Windows scripting host can be used for scripts: VBScript and JavaScript by default, Perl, Python, Rexx, TCL, PHP, XSLT and any other for which extensions are installed in Windows. - No need to implement OLE-server functionality for application or any object to be shared with scripting engine. - Any object descending from TPersistent can be added to script's namespace and operated within script environment, including all of its published members. - Any object descending from TComponent can be created within script and operated by script or by application after script is finished. - Recently used events of VCL components can be handled by script procedures (and you can add new events very easy if having source code of TekWSHControl component). - If control is added during script executing (in script procedure), event handlers for it are set automatically if any defined in script's body. - If control exists independently from scripts, event handlers for it may be set just by one line of code (like "Panel1.OnClick:= ekWSHControl1.OnClickHandler", and then event handling is redirected to script's procedure "Sub Panel1_OnClick()", if such present in scripts body). - Native VCL code. - Simplicity of use. - All Delphi versions from 4 and higher support. 6. Quick start with this script component The set of demo projects coming with scripter package contains almost all possible aspects of using component. Loading and running scripts (whole script and/or individual procedures and functions contained in script body), adding Delphi objects to script environment, operating with objects and their properties in script, calling Delphi methods from script, passing parameters to script routines, using universal script language extensions provided by control and other related tasks. It is enough to look at demo code (Delphi and script sources) to start using control in very advanced mode.