Scripted Spell Check (Settings/Preferences tab)

In addition to the built-in spellcheck window, another method of intercepting questions containing words not understood by the system is by applying a Spellcheck script. The "Scripted Spell Check" check box indicates whether some script in the script library should be used either in place of, or in addition to, the normal spellcheck window. Checking this box will have no effect unless the name of a valid script is first entered into the grey box immediately below the "Scripted Spell Check" checkbox.

Script libraries must be created by the user or an administrator. The script library for a given View is initially empty; that is, the Scripts tab of the Settings window has no entries. Scripts are written in either of two popular "scripting" languages, JScript and VBScript. These languages are well-understood by many Web designers and other programmers, even those with only basic coding skills. While the following is not a tutorial on using scripting languages, it does explain the use of scripting in the context of ELF spellcheck scripts.

Spellcheck scripts work in some ways like most ELF scripts. They must be given a single word name (underscores are permitted). For example, we might call our spellcheck script Re_Speller. To define this script, enter Re_Speller into the Script Name column of the Scripts panel. We'll then enter an empty stub for the Re_Speller script to give us a place to start working. The stub will look like this:

function re_speller


end function

Most ELF scripts work by returning a value as the function result. Spellcheck scripts work differently; they consult a built-in variable called SpellCheckIn to find the misspelled word, and pass the corrections back out in a variable called SpellCheckOut. A very simple spell check script, which handles one and only one spelling error, might look like this:

function re_speller

   if SpellCheckIn="speciailty" then SpellCheckOut = "specialty"

end function

With this script in place and active, a question containing the misspelling "speciailty" will be automatically corrected behind the scenes. Since the user won't need to deal with the spellchecker, this kind of enhancement can be very useful for handling both common misspellings and alternate spellings.

An important caveat concerning alternate spellings is the fact that the alternate must be totally unknown to trigger the spellcheck process. If the alternate appears within the reference (Moby) dictionary, Access ELF will use the alternate as-is, and that alternate may not carry the same connotations. Another problem occurs if the alternate is a conjugated form of a known word. For instance, if the line above were changed as follows:

if SpellCheckIn="speciality" then SpellCheckOut = "specialty"

you might think that this script would intercept a question like "list unit price of speciality products". Actually, it won't. The reason is that the script never fires at all, since Access ELF never sees a "misspelling". When "speciality" is not found in any dictionary, ELF then strips the "y", "ty" and finally "ity" from the stem and succeeds in finding the word "special". It's a sad fact that, at the current level of the technology, ELF is unable to guess that "special" and "specialty" are close-enough-cousins to mean the same thing.

Of course there are many ways to handle this kind of exception. We could simply define "speciality" as a synonymn for "specialty". We could add a Phrase macro which substituted the word "specialty" for the word "speciality":
When I Type: speciality    I Really Mean: specialty

We could also define a Phrase macro which substituted the string "specialty" for the string "speciality":
When I Type: [speciality]    I Really Mean: specialty

Notice that the only difference between these two techniques is the order they're applied in relation to other substitutions; for more on this, see the topics related to Phrase macros.

Finally, we could include this case among those handled by a Phrase script. A Phrase script definition would look similar to the Phrase string definition above, except that it would have no entry for the "I Really Mean" part; instead it would have the name of a script (say, "Exceptions") in the ScriptName column.

When I Type: [speciality]    I Really Mean:     ScriptName: Exceptions

Phrase scripts work by returning the replacement value for the word or phrase as the function result. Here is a simple example of a phrase script which could exchange "specialty" for "speciality" in the text of a question:

function Exceptions

   if PhraseTrigger="speciality" then Exceptions = "specialty"

end function

Of course, this simple example doesn't call for the full range of power available with Phrase scripts. Generally, a phrase script would handle a variety of cases, and might be used only when complicated rules for such substitutions were needed, rules beyond the expressive capability of the Phrase macro language. See the Northwind examples and the Phrase script topics for more details.

In the example (at top) of a basic Spellcheck script, the script was used to intercept the error before the Access ELF Spelling window could appear. SpellCheck scripts will trigger both before and (optionally) after popping up the Spelling window. You can determine whether the script is firing before or after the Spelling window appears by checking the value of the SpellCheckOut variable. SpellCheckOut holds "?" if the script is triggered before, otherwise it holds the correction provided by the user from the Spelling window

Most often, you'll want to intercept common spelling errors and simply replace them without bothering the user with a pop-up window. For this, set the SpellCheckOut value to the word you want to replace the misspelling with. (The mis-spelled word is available in SpellCheckIn.) If you do this, the pop-up Spelling window will never appear. This is how we designed the above example.

But SpellCheck scripts can 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." Assuming this information is not authorized for publication, you may intend the Question script as a security safeguard. For example, it could deal with any questions mentioning "sex" or "gender" by setting the PrivateErrorCode variable to -8 with a error message explaining that this information is not published.

This works for nearly all cases. But -- you don't want a clever 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 modified input to make sure it's not one of your proscribed terms.

Let's return to the re_speller example above and ask what would happen when the list of exceptional cases grew large enough that it became desirable to store spelling corrections in a database table, rather than within code.

function re_speller

   if SpellCheckIn="speciailty" then SpellCheckOut = "specialty"
 . . . . .
   if SpellCheckIn="ecxeption" then SpellCheckOut = "exception"

end function

Instead of making an addition to this script each time we find a new spelling error, we want a simple piece of code which will apply to an easily-managed table of known errors.

Here's that simple piece of code!

function re_speller

   On Error Resume Next
   result = Evaluate("DLookup(""Correction"",""Spellfix"",""Misspelling='" & SpellCheckIn & "'"")")
   if Len(result) then SpellCheckOut = result

end function