The Scripting Engine opens in its own window, and appears as a second icon in the Windows task bar. When open, it also appears under switch windows located in the Jim2 Quick Access Toolbar.
The fully featured scripting engine supports:
▪Multiple script editing
▪Editor code folding
▪Debugger break points
▪Code completion (Shift+space within the code editor)
▪Code helper palette (available functions, variables, types, etc)
▪Tool palette (form component selection etc)
▪Object inspector with properties and events editor
▪Unit Code, Design and Info tabs
▪Debug panel with Local Variables, Watches and Call Stack
▪Report selection (allows execution of script against selected report within the scripting engine).
Library scripts are used for scripted Jim2 functions, such as the creation of ABA files, and for common code to be shared across multiple scripts. They can be included in scripts via the object Pascal Uses Unit syntax.
Server Side Scripting
The script and report run on your server, rather than locally on the Jim2 client. The main advantage of this is that, if a script can run server side, the associated report is available via Jim2 Mobile.
Several key system scripts run server side, which enables their associated reports to be available on Jim2 Mobile, including:
Examples of related System Reports
CardFiles > CardFiles > Statement
Debtors > Debtors > Statement
Invoices > Invoices > InvoiceSale
Invoices > Invoices > InvoiceSaleSimple
Invoices > Invoices > InvoiceService
Invoices > Invoices > InvoiceServiceSale
Jobs > Jobs > Job Receipt
Jobs > Jobs > Job-Onsite
Job w/o Logo
Jobs > Jobs > Job
Jobs > Jobs > Manufacturing Job
Jobs > Jobs > Job No Comment
Separating User Input from Report Generation
Typically, scripts are executed from the Jim2 client by calling the script’s Run (DesignMode: boolean) procedure. When called from the report toolbar, DesignMode is false, and when called from within the Report Designer, DesignMode is true.
The scripting engine can be open and used whilst still using the Jim2 client. As such, scripts have direct access to the currently opened object (job, quote, etc).
Server-side scripts require no user interaction, and have any report parameters (typically entered by the user via the script's associated form) passed to them via a JSON record.
A report that supports server side scripting is executed, calling the script’s RunServerSide (jsonstr : string) procedure. The variable jsonstr contains the report parameters. For example, the job script contains the following procedure:
procedure RunServerSide( jsonstr : string );
DesignMode := False;
ReportParams := JSON.Parse( jsonstr );
qJimJob := CreateComponent(self, ‘TFDQuery’);
qJimJob.Connection := DM.JimConnection;
qJimJob.SQL.Text := ‘SELECT * FROM JimJob Where JobNo = ‘ + ReportParams.jobNo;
if (qJimJob.EOF) then
raise Exception.Create( ‘JobNo ‘ + ReportParams.jobNo + ‘ does not exist’ );
A script can, and should, be coded to support both client side and server side execution, noting that some resources available client side (for example, the actual form and its properties) are not available server side.
To handle both sides, the scripting engine supports compiler directives to include/exclude client side and server side code as required.
For example the Statement script contains the following code that uses the SERVER_SCRIPTING compiler directive:
EmailSubject := ReportName + ‘ for’ + qCardFile.FieldByName(‘CardCode’).AsString + ‘ ‘ +
‘ for Date ‘ + ReportVar1;
EmailSubject := EmailSubject + ‘ from ‘ + CompanyName;