Access ELF Documentation Access ELF Tutorials Access ELF On-Line Help Access ELF Downloadable Help File Access ELF FAQ VB ELF Documentation VB ELF Tutorials VB ELF On-Line Help VB ELF Downloadable Help File VB ELF FAQ
Configuration & Licensing Options
Critical Opinions
Our Users Talk Back






Scripting


Access ELF incorporates the Microsoft Scripting Control, letting you enhance your interfaces by leveraging your own programming skills. First, you can use scripts to determine which View to use in answering a given question. The script (called a Question script) will choose the View based on logic you program, testing the question text, the user's log-in ID, or anything else available in the script's runtime environment (eg. system clock, via the Now() keyword). You can use this not only to increase the responsiveness of your interfaces, but to implement security as well.

The crucial use of scripting is discussed below, and in the Question Script topic.

You can also attach a VBScript/JScript program to any given word or phrase, so that it's triggered when the phrase is used in a question. Each Phrase script is given a one-word identifier, which is also the name of the function within the script which will be run when the script is triggered. This function can call other functions defined in the same script panel (or included from a library of functions). The return value of the function will be used as a replacement for the trigger phrase.

To get started with this feature, you can write a simple script:

function MyName
    MyName = InputBox("Type your name: ")
end function

Copy this script into a blank Script tab panel (right), and enter the identifier MyName in the ScriptName box (left).

Now try adding a line to the Phrases list (ABC on the Toolbar).
When I Type: [me]    Script: MyName

This shows how you can make phrase replacements completely interactive. Of course, you might want to program an advanced system that makes substitutions based on the circumstances. Here's a slightly more useful example:

When I Type: [my accounts]    Script: MyAccounts

(both functions must go into the same script panel)


Function Accounts
     If UserID = "BobG" then
         Accounts = "the Smith accounts"
     Else
         Accounts = "the Jones accounts"
     End If
End Function

Function MyAccounts
     MyAccounts = Accounts
End Function

We've provided some useful information to get you started. Within any script, you can reference any of the properties or methods in this updated interface definition.

The Question is what's typed into the query box.

Connection is the OLE DB connection string.
[ Unused in Access ELF; see VB ELF documentation.]

UserID is the ID of the current user on the machine.

Password is not set unless you set it. It will be remembered from question to question, so you can use it to store a password for user log-in validation.

PrivateErrorCode is used to pass values from earlier-firing scripts (triggered by a Question or a Phrase) to scripts triggered later in the translation process. Usually an Answer script will have code to react to this signal, using it for instance to generate an error message or to run a pre-built query with parameters selected according to the question.

SQL is the SQL translation and can be read only by Answer scripts.

QueryResult is the numeric code for the processing result. It can be read to find out whether the SQL translation suceeded or failed, and how. It can also be set on exit of an Answer Script to change how, or whether, Access ELF will proceed to displythe answer. For instance, to substitute a custom error message, set this value to -8 in your script and set the ErrorMessage property as follows: ErrorMessage="Message I Want Displayed;Optional Header for the Message" (See table of Query Result codes.)

Execution Error codes can only be set during SQL Server 7.0 processing
-7 indicates numeric overflow; -8 indicates a timeout error. [ Unused in Access ELF ]

SpellCheck scripts will trigger both before and after popping up our spell-check window. The SpellCheckOut property holds "?" if the script is triggered before, otherwise it holds the correction that the user has supplied for the misspelled word.

You might want to intercept some common spelling errors and simply replace them without bothering the user with a pop-up window. To do this, set the SpellCheckOut value to the word you want to replace (the misspelled word is available as SpellCheckIn). If you do this, the pop-up spell-check window won't appear at all.

SpellCheck scripts also trigger after the pop-up window closes. The main purpose of this is to avoid a security hole. For example, lets say you write a Question Script which detects questions like "Show the sex of employees." The security script might deal with this by just setting the PrivateErrorCode. Post-translation, the Answer script can react to the value with an error message explaining that this information is not published. You don't want a hacker-type to then simply type in "Show the seZx of employees." and use the spell-corrector (which fires after the Question script) to subvert the security system. If a SpellCheck script fires and SpellCheckOut is not "?" then it's the correction the user selected from the pop-up window. You can then inspect that to make sure it's not one of your proscribed terms.

To see exactly what's going on with script processing, you can set the Debug Script flag on, which will show you the input and output of each script every time it fires.

The CurrentViewName property lets the script know which View has launched it. (Actually, this is redundant since a script can only be launched by the View that owns it. This property dates from when Scripts were shared by different Views of the same database.)

The Resource property is similar to the PrivateErrorCode property, in that it is intended as a way for scripts to interchange information. While PrivateErrorCode can only hold a number, Resouce can hold any type of information, for instance string data. This makes it ideal for packaging up parameters within a Question script for delivery to an Answer script. For example, if a question script detects the words "Chicago" and "dog" (in a hotel availablility database), the next step might be to run a query that accepts a city name and type of pet parameter, returning hotels in that city accepting that pet. The Question script would assign

Resource="[City Name];Chicago;[Type of Pet];dog;"
PrivateErrorCode=765

The AnswerScript might have code to handle this case, such as:

function SpecialAnswers
   if PrivateErrorCode=765 then
      QueryParms=Resource
      SpecialAnswers=HotelsByCityAndPet
   end if
end function


See a related example in the VB ELF Compatibility section.

The PhraseTrigger property allows a Phrase script to know the exact phrase which triggered its invocation. This might be useful in two different situations:

  • if the same script is attached to two different triggers
  • when a script is attached to a trigger with a data-aware trigger

In the first case, testing this property will tell us which trigger fired the rule. In the second case, the trigger is partly a variable. For instance, a trigger such as [all {CATEGORY}] can be matched by any of the following: all beverages, all seafood, all produce etc. The PhraseTrigger property will in each case hold the italicized phrase. In contrast, the DataTrigger property will hold only that part of the question which matched the field variable (in these three cases, DataTrigger would hold beverages, seafood, and produce respectively.

The same type of purpose is served by the NumberTrigger property. It's used in cases where any numeric value can help trigger a rule, such as [${#} worth] If such a trigger is linked to a Phrase script, the script can read the amount following the dollar sign by consulting NumberTrigger.

The WarningCode property is used by a script to request that Access ELF fire a message box when it finishes processing the current question. The text of the message box will be the value of the WarningString property. To maintain consistency, these two properties should be set (or cleared) at the same time by the same script. The WarningString can optionally specify the caption and optional icon for the message box. The syntax of the WarningString is:
Message[;Caption][;MsgBoxCode]
For example, to launch a message box, using the default "Access ELF" caption, but with an Exclamation icon, you'd use:
WarningString = "That's a good question! ; ; 48;"

To provide a caption, insert text in the blank area between the two semi-colons. This example uses the Critical Message code (see Microsoft's MsgBox Constants documentation).
WarningString = "That's a very bad question! ; Administrator notified ; 16;"

Note that because of the use of semi-colon as delimiter, warning messages cannot contain semi-colons.

As of Access ELF 2002, the following properties have been added to the above list.

Public Phrase As Variant ' 12/01; to help construct appropriate warning messages via script
Public DataTrigger2 As Variant ' 12/01; to pass a second data-trigger to script
Public PhraseReplacement As Variant ' 1/02; the text which will replace the PhraseTrigger text
Public QuestionReplacement As Variant ' 1/02; full results of any replacement (including inversions)

DataTrigger2 holds the part of the trigger which matches any second instance of database specific input. In the following rule, the value of DataTrigger2 passed into the script Interpreting might be "Davolio".

When I Type: [{FirstName} {LastName} sales]
I Really Mean: sum subtotal for {1} {2}
Script Name: Interpreting

The Phrase property holds the literal text of the Phrase field for the rule which fired the script. This may contain variables such as {1}, {2} or {#} which refer to data or numeric markers in the trigger. This is essentially provided for completeness only. An extended version of the provided Interpreting example might include code to show how the PhraseReplacement property was built-up step-by-step, starting with the Phrase, and showing each modification made. (For example, replacing "{1}" with the value of DataTrigger. Note however that if the replacements were actually made via the phrase-replacement language -- not the script itself -- then the logic of the replacement rule would have to be programmed into the script as well.)

The PhraseReplacement property holds the full text of the replacement phrase, after all logic is applied and replacements have been made. (This is why the example linked to above requires so little code.)

The methods available to any script are linked below to examples of their use (some immediately following):

Public Sub SetDirectoryPath(PathSpec)   Show Me
Public Function OpenView(ViewName) As Integer   Show Me
Public Sub AddAttribute(Entry, myAttribute, myType)   Show Me
Public Sub SelectGrammarLayer(Layer%)   Show Me
Public Function ExecuteSQLCustom(SQL, Optional whichDB)   Show Me
Public Sub AppendFunction(Func, Tokentype, domain, Domain2, range)   Show Me
Public Sub AddVerbMapping(DBName, Table1, Field1, Table2, Field2, LinkVerb)   Show Me
Public Function Evaluate(thisStatement)   Show Me 1, Show Me 2, Show Me 3


Question Scripts

The most important use of scripts has been left for last. Until Scripting, there were only manual methods for switching between Views. (Views are ELF interfaces, defined on a particular set of related tables.) Although it's extremely useful to narrow the selection of tables to improve interface accuracy, this hasn't been popular in the past -- because it required the user to select the proper View. Not any more! Question Scripts can choose the View that should be used to answer any given question, after it's typed in. For example, you could use the UserID and any keywords you find in the Question to decide to answer the question with View X instead of View Y. Or use anything else you can program in VB -- for instance, the time of day (Now() function). The result returned by a Question script should be the name of a valid View (if you return nothing, for instance using the script to modify or validate the question, then the currently selected View is used).

The Methods are provided as a way for your scripts to directly set the operative View, without returning a value from your function. The reason you might want to do this is in order to reset the PATH where grammars (.ELF subdirectories) are located, at the same time you shift Views. To change the path, use the SetDirectoryPath method. For instance,

SetDirectoryPath "f:\applications\elf\grammars"

Now your function can return the name of a View located in that directory. Alternatively, you can set the View yourself, for instance:

result = OpenView("MyFavoriteView")

The result is True is successful, False if not. Including the OpenView method seems redundant at first glance, since you can set the View by returning its name from your script. The one case in which it's not redundant is if you have multiple Views with the same name located in different directories. If you switch directories and return the name, VB ELF will see that the name hasn't changed, so it won't reload the grammar.In that case, you'd need to use the OpenView function directly.

To change the scripting language from VBScript to JScript, click the appropriate radio button on the Advanced tab of the Settings window. One default scripting language is permitted per Access ELF installation. For instructions on changing the Scripting language via script, see the How To section.

Please see the section on VB ELF Compatibility Enhancements for a breakdown of enhancements made to the scripting components since the version 3.0 release. These include the ability to create script function libraries (via use of #include commands), and the introduction of data-aware triggers (passed into PhraseScripts).


Last Updated: August, 2009