Frequently asked support questions
Problem: The Add button is disabled in the spelling dialog, so words cannot be added to a user dictionary.
Solution: The Add button is enabled only if a user dictionary is available to which words can be added. If the user removes all user dictionary files, then the Add button will be disabled. If user dictionary files are defined but can't be opened for some reason (e.g., the files do not exist or the path listed in UserLexPath is incorrect), the Add button will be disabled.
Clarification: Differences between "Basic API" and "Windows API" |
The SSCE DLL contains two API "layers:" The "basic API," which contains no user-interface and is independent of any particular operating system, and the "Windows API," which is specific to Microsoft Windows. Distinctions between the two APIs is a frequent source of confusion.
If you program entirely at the basic API level, your application must take responsibility for opening a session (via SSCE_OpenSession), opening lexicons (via SSCE_OpenLex), and setting any required options (via SSCE_SetOption). Because the basic API is platform-independent, it does not read from the system registry or SSCE.INI file (which are both Windows specific).
To make integration easier for Windows developers, the SSCE DLL can automatically perform some of the basic API "housekeeping" tasks. The DLL will automatically open a session, read the SSCE.INI file (16-bit DLL) or system registry (32-bit DLL) to determine which lexicons to open and which options to set, then open those lexicons and set those options. This is described in the SSCE Programmer's guide section titled "About SSCE in the Windows environment." Because this housekeeping work is done automatically, an application can call any function in the SSCE Windows API (such as SSCE_CheckCtrlDlg) without having to perform any initialization.
An application which needs to use the basic API can take advantage of automatic housekeeping done by the SSCE DLL by using the SSCE_GetSid function. SSCE_GetSid returns the session id of the session automatically opened by the SSCE DLL. This session will have open lexicons and option settings according to the properties defined in the system registry or SSCE.INI file. This is described in the SSCE Programmer's guide section titled "How to call the basic SSCE API."
If your application calls SSCE_OpenSession itself, the opened session will initially have no lexicons open and only the default options set. You would have to call SSCE_OpenLex and SSCE_SetOption to open lexicons and set options.
If your application calls SSCE_OpenSession, it should call SSCE_CloseSession before terminating.
Your application should not call SSCE_CloseSession to close the session id returned by SSCE_GetSid. The SSCE DLL will automatically close the session when your application terminates.
Problem: When your application calls one of the spell-checking functions in the SSCE DLL (e.g., SSCE_CheckCtrlDlg), SSCE displays message boxes reporting that it can't open some or all of the dictionaries.
Solution: This problem is almost always the result of a misconfiguration or a file problem. See the solutions in "Most or all words reported as misspellings".
"Error replacing word (probably out of space)" error message |
Problem: When checking text using SSCE_CheckCtrlDlg or SSCE_CheckBlockDlg with the showContext parameter set to TRUE, the message "Error replacing word (probably out of space)" appears when the user clicks the Change button in the spelling dialog.
Solution: Standard text controls in Windows can hold about 32K of text. If this limit is reached, any attempt to add characters to the control will fail. The error message is displayed if an attempt to add characters to a text control fails. When the showContext parameter in SSCE_CheckBlockDlg is set to TRUE, the spelling dialog displays the text being checked in a text control which has the same 32K limit.
If you are using SSCE_CheckCtrlDlg, the solution is to use a rich-text control instead of a text control. Rich-text controls have a limit of about 16Mb. If you are using SSCE_CheckBlockDlg, break the text into smaller chunks that will fit into the 32K limit with room for expansion.
Question: Is it possible to place dictionary files on a common network file server so they can be shared by all users?
Answer: Yes. If you are using the SSCE Windows SDK, just set MainLexPath to the drive/server and path containing the dictionaries:
MainLexPath=g:\dict
or
MainLexPath=\\SERVER\\dict
If you are calling SSCE_OpenLex directly, pass the full path name of the dictionary file on the server.
We do not recommend sharing editable user dictionaries, however. If all users share an updateable dictionary, one user can compromise the effectiveness of the spell checker for all users by adding a misspelled word. We recommend that each user have his or her own user dictionaries. If you want to have a common dictionary containing site-specific words, add it to MainLexFiles like this:
MainLexFiles=ssceam.tlx,ssceam2.clx,ourwords.tlx
and have an administrator carefully update it as needed.
Question: Your documentation says I can use Word's dictionaries, but a) I don't know how or b) when I try, it doesn't work.
Answer: The first thing to note is that we claim SSCE works with other applications' user dictionaries. We have been very careful to always qualify "dictionary" with "user" when describing SSCE's capabilities in our Web pages and programmer's guide. SSCE cannot use Word's (or any other application's) main dictionary for technical and legal reasons.
The user dictionary is typically a small text file containing words the user added, such as the user's family name, street name, business name, etc. In Microsoft Word, the user dictionary is often called custom.dic. To find the names of the user dictionaries Word knows about, select (in Word) Tools + Options + Spelling & Grammar, then click on the Dictionaries... button. The dialog that pops up shows the path to the user dictionaries plus a list of user dictionary files. Knowing the path name and the user dictionary file name, you can add the user dictionary to the UserLexFiles property, or use the Add button in the SSCE Dictionaries dialog to locate and add the file.
Problem: My application works OK on my development system (where I installed the SSCE SDK), but when I install it on another machine, SSCE reports that all words are misspelled, or that it can't open dictionaries.
Solution: This problem is usually the result of a misconfiguration of some kind. Following are some suggestions:
Read the section titled "How to install the SSCE run-time with your applications" in the SSCE Programmer's Guide. Note that there are two sections with this title in the guide, one for Windows applications and one for applications which use the SSCE Source SDK. Make sure you are reading the section in the right chapter.
Customers are sometimes confused about whether the SSCE DLL reads the SSCE.INI file or system registry. The 16-bit SSCE DLL (SSCExx16.DLL) always uses the SSCE.INI file, regardless of which operating system it is running on. By default, the 32-bit SSCE DLL uses the system registry when it runs on a 32-bit operating system (Win95/98/NT), and the SSCE.INI file when it runs on a 16-bit operating system (Win3.x) under Win32s. Starting with version 5.13, the 32-bit SSCE DLL will access properties in an INI file after the SSCE_SetIniFile function has been called. You will need to configure the SSCE properties in the registry or INI file depending on which DLL your application uses and which operating system you are installing to.
Problem: During linking, the linker reports that functions in the SSCE API (e.g., SSCE_CheckCtrlDlg) are not found.
Solutions:
-
Make sure that the WIN16 or WIN32 preprocessor symbols are defined.
-
If you are compiling with a Borland (Inprise) C++ compiler, you will need to create new .LIB files from the SSCE DLLs using the IMPLIB utility. IMPLIB is provided with the Borland compiler. Run IMPLIB, specifying the SSCE DLL (16 or 32 bit) as the source. Use the .LIB files created by IMPLIB when linking your application.
Problem: When you pass the handle of a 3rd-party edit control to SSCE_CheckCtrlDlg, nothing happens, or the results aren't as you expect.
Solution: SSCE_CheckCtrlDlg communicates with the control being checked through standard messages such as WM_GETTEXTLENGTH and WM_GETTEXT. This technique works with standard text and rich-text boxes. Unfortunately, many 3rd-party controls do not respond to these messages, or they respond in non-standard ways. The following technique can be used to check the words contained by a control provided the following is true:
- The control provides some way of getting the unformatted text as a simple string of ASCII or ANSI characters. Sometimes this is done through the control's Text property. If the control doesn't provide a direct way of getting the unformatted text, one method that may work is to copy all the text to the clipboard, then access the clipboard contexts as text (i.e., using the CF_TEXT format).
- The control provides a mechanism to select text using
an offset and a length.
- The control provides a mechanism to replace the selected
text with new text.
- Formatting (e.g., font changes) applies to entire words only and not to partial words. For example, no font changes occur in the middle of a word.
If all the above conditions are met, the following technique can be used to check the text contained by a control, highlight misspelled words, and correct misspellings. Note that this technique involves calls to the "basic" SSCE API. Wherever a session id (sid) is needed by a basic SSCE API function, call SSCE_GetSid to obtain the session id used by the SSCE DLL. See the SSCE Programmer's Guide for detailed descriptions of each function.
- Extract the unformatted text from the control, and call SSCE_OpenBlock to open a block containing the text. Be sure to allocate room for growth.
- Call SSCE_CheckBlock to check the spelling of words in
the block. Call SSCE_CheckBlock in a loop until it returns
SSCE_END_OF_BLOCK_RSLT.
- When SSCE_CheckBlock detects a misspelled word, call SSCE_GetBlockInfo
to obtain the offset of the word (the block's cursor position).
Tell the text control to select (highlight) the number of
characters indicated by the length of the misspelled word,
starting at the word's offset. Call SSCE_CheckBlockDlg to
check the misspelled word; this will give the user the opportunity
to look up suggestions, enter a correction, etc. When SSCE_CheckBlockDlg
returns, check if the user changed the word (compare it
with the misspelled word). If the user changed the word,
tell the text control to replace the selected text with
the changed word, and call SSCE_ReplaceBlockWord to replace
the word in the block. Call SSCE_NextBlockWord to advance
to the next word.
- When SSCE_CheckBlock reports that the end of the block has been reached, call SSCE_CloseBlock.
Problem: When you check the contents of a text box (edit control) using SSCE_CheckCtrlDlg, misspelled words are not highlighted.
Solution: Make sure the text box has the Hide Selection property set to False. If you create the control yourself, make sure the ES_NOHIDESEL edit style is set. See "How to check an edit control or rich-edit control" in the "Using the SSCE Windows API" chapter of the SSCE Programmer's Guide for more information.
How to prevent conflicts with other applications which use SSCE |
If your application is installed on the same computer as another application which also uses SSCE, conflicts can result that may disable spell checking in either or both applications, or which may cause other problems. Fortunately, there are some steps your application can take to prevent this from occurring.
The SSCE DLL is named to prevent incompatibilities caused by changes to the SSCE API. Each time the SSCE API is changed, the SSCE DLL name is changed. Thus, you can be assured that if you link your application with SSCE5232.DLL, for example, all instances of SSCE5232.DLL will contain the functions and parameters your application expects. SSCE DLLs with other names (e.g., SSCE5332.DLL) have a different API version, and may not work correctly with your application.
Similarly, the compressed lexicons (dictionaries) used by SSCE have different names depending on the file-format version. (The naming convention used for compressed lexicons is documented in the SSCE Programmer's Guide under "About SSCE's lexicons" in the "Introduction" chapter.) Two or more applications can share the same compressed lexicon without conflict, provided each application uses a version of SSCE which is compatible with the lexicon's file format. You can determine which lexicon version is right for your SSCE version by examining the names of the American or British English lexicons included with SSCE. If the American English lexicon in your version of SSCE is named SSCEAM2.CLX, then you should use only lexicons with that file-format version (2) and not other versions, such as SSCEAM1.CLX.
The SSCE DLL provides built-in dialogs and other convenience functions to simplify operation in the Windows environment. To implement this, the DLL automatically opens lexicons and sets user options. All applications which share the same SSCE DLL and use the built-in dialog functions (e.g., SSCE_CheckCtrlDlg, SSCE_CheckBlockDlg) also share the open lexicons and options. If one application changes an option, all sharing applications will be affected. In practice, this is not as bad as it sounds, because option settings are usually made on behalf of the user, and the same user is operating all sharing applications, so the chances are good that the user wants the option setting to apply to all spelling checks he or she performs. Nevertheless, in some cases you may want to insulate your application from the effects of changes made by other applications, and techniques for doing so are described below.
The SSCE DLL obtains information about which lexicons to open automatically and which options to set from either the system registry or an INI file. Starting with version 5.13, the 32-bit SSCE DLL can be instructed to obtain settings from either the registry or an INI file. In versions 5.12 and earlier, the 32-bit DLL always obtains settings from the registry, and the 16-bit DLL always obtains settings from an INI file. The use of each is described in the following paragraphs.
By default, the 32-bit SSCE DLL obtains its settings from the Software\Spellex\SSCE tree under HKEY_CURRENT_USER (versions of SSCE prior to 5.11 also obtained some settings from the HKEY_LOCAL_MACHINE tree). If two applications which use the 32-bit SSCE DLL are installed on the same machine, and both let the SSCE DLL use the default registry tree, and each have incompatible settings, then problems will arise. Typically, the last application installed will get the settings it needs, and the previously installed application will no longer work. To prevent this from happening to your application, configure SSCE settings under your application's registry tree when it is installed, and call the SSCE_SetRegTreeName API function before you call other SSCE Windows API functions, such as SSCE_CheckCtrlDlg. This will cause the SSCE DLL to get its settings from your application's registry tree, which settings should be appropriate for your application. For better efficiency, your application can call SSCE_GetRegTreeName first, and call SSCE_SetRegTreeName only if the current registry tree is not your application's tree. (A race condition exists, in that another application could call SSCE_SetRegTree name after your application calls SSCE_GetRegTreeName or SSCE_SetRegTreeName, but the chances of this happening are very small.)
By default, the 16-bit SSCE DLL obtains its settings from the SSCE.INI file. The SSCE.INI file is searched for in a specific way; see "How SSCE locates the SSCE.INI file" in the "About SSCE in the Windows environment" section of the "Using the SSCE Windows SDK" chapter of the programmer's guide. If two applications which use the 16-bit SSCE DLL are installed on the same machine, and each have incompatible settings, then problems may arise. The SSCE DLL will use the settings in the first SSCE.INI file it finds, which will likely be associated with the first application to start. Also, if both applications install the SSCE.INI in a common directory such as the Windows directory, then the last application to be installed may overwrite the settings of a previously installed application. To protect your application from problems of this sort, call SSCE_SetIniFile before you call other SSCE Windows API functions, such as SSCE_CheckCtrlDlg. This will cause the SSCE DLL to get its settings from your application's SSCE.INI file (or other INI file), which settings should be appropriate for your application.
Other information related to incompatibility problems:
-
Under Windows, DLLs are located by module name, not file
name. Placing a private copy of the SSCE DLL in your application's
directory does not guarantee your application won't share
the DLL with other applications, because Windows will
use the loaded copy of the DLL if the module names match.
- If your application calls SSCE_OpenSession, then any settings
made within that application will be private to your application,
so there is no need to worry about incompatibility problems.
- SSCE Windows API functions which begin with SSCE_Set usually
save the settings in the current registry tree or INI file.
Call SSCE_SetRegTreeName (32-bit DLL only) or SSCE_SetIniFile
before calling a SSCE_Set function to ensure the settings
are saved where you expect them to be saved.
- If your application calls SSCE_GetSid to share the session automatically opened by the SSCE DLL, it should not save the session id. Instead, call SSCE_GetSid each time you need the session id (e.g., call SSCE_CheckWord(SSCE_GetSid(), ...)). It's possible for other applications running on the same system to perform actions which would make the saved session id invalid. Calling SSCE_GetSid each time ensures the session id will be valid.
How to use alternate dialog box template resources in Visual Basic |
The appearance of the dialog boxes built in to the Spellex Sentry DLL can be modified at run time by supplying alternate template resources. This article describes how to do this in Visual Basic. The approach described here is known to work in Visual Basic version 6. It may or may not work in other versions.
General information on using alternate dialog box templates with the Spellex Sentry DLL is available in the Spellex Sentry programmer's guide: "How to change the appearance of Spellex Sentry's dialog boxes" in the "Using the Spellex Sentry Windows API" chapter.
Before you can work with resource files in Visual Basic, you must first load the Resource Editor Add-In. To load the Resource Editor Add-In, select Add-In Manager from the Add-Ins menu. In the Add-In Manager dialog box, select VB6 Resource Editor and check the Loaded/Unloaded box.
To create a resource file:
-
Select Add New Resource File from the Project menu.
-
In the Open A Resource File dialog box, enter a name for the resource file. Be sure to give the file a .res extension. The resource file will be added to the Related Documents node in the Project Explorer.
To edit a resource file:
-
Select Resource Editor from the Tools menu.
-
Select a button from the Resource Editor Toolbar to edit an existing resource or add a new one. To learn more about editing resources, see the Resource Editor Add-In documentation.
Alternatively, you can use a resource editor and resource compiler provided with a different product, such as VC++. After creating and editing the resource file, compile it using the resource compiler to create a .res file. The .res file can then be added to the Visual Basic project.
Note that the dialog template resources will not be available if you run your project from the Visual Basic IDE. You must create a .exe file before your dialog template resources will be available.
For more information on using resources in Visual Basic, see the following topics in the Visual Basic documentation:
-
Visual Basic Concepts: Using Resource Files for Localization
-
Visual Basic Concepts: Working with Resource Files
-
Resource Editor Reference: Resource Editor Add-In
Problem:
- The Spellex Sentry DLL will check only the selected text, regardless of the value of the "selectedOnly" parameter passed to SSCE_CheckCtrlDlg.
- The Spellex Sentry DLL fails to find any misspelled words in the control's text, even though I am sure there are at least one.
- When misspelled words are corrected, the Spellex Sentry DLL inserts the corrected word in front of the misspelled word, or in some other way mixes up the misspelled word and corrected word.
- When misspelled words are corrected, the text control is not changed.
- When misspelled words are highlighted, the highlighting is incorrect, so the highlighting covers only part of the misspelled word and part of the preceding or following word.
Solution:
All of these problems are likely caused by the behavior of the text control. The Spellex Sentry DLL sends messages to the control to ask it for the text it contains, highlight a specific word, and replace the highlighted text with new text. If the control responds to the messages in unexpected ways, various incorrect things may happen.
The SSCE_CheckCtrlDlg function (or the Check(CWnd *) and Check(HWND) methods in the CSentrySpellDlg class) can communicate with standard edit and rich-edit controls and text boxes ("standard" means the controls which ship with the Windows operating system). Some development environments, including Delphi and Visual Basic, provide superclassed versions of the standard controls. The superclassing affects the control's behavior and may make it incompatible with the Spellex Sentry DLL.
The Spellex Sentry DLL determines what kinds of messages to send to the control based on the type of control, which it determines from the control's window class name. The Spellex Sentry DLL knows the class names of the standard controls, but may not recognize the window class names of superclassed controls. If the Spellex Sentry DLL does not recognize the window class name of the control, it assumes it is a simple edit control, and sends messages appropriate to that control type. If the control is a different type, the messages sent by the Spellex Sentry DLL may not be the right ones.
If you encounter problems similar to the ones noted above, it may help to tell the Spellex Sentry DLL which underlying standard control is used by the control you want to use. To do this you will need two pieces of information: 1) The window class name of the control you are using; 2) the window class name of the standard control on which your control is based. The people who support your development environment should be able to provide this information. The topic "Using the Spellex Sentry Windows API" / "Checking Controls Interactively" / "Checking third-party controls" in the Spellex Sentry programmer's guide contains instructions on how to map your control's window class name to the class name of a standard control.
If all else fails, you can get the text from the control into a string, then use SSCE_CheckBlockDlg (or the Check(CString&) method in the CSentrySpellDlg class) to check the string's contents. This isn't as nice as checking the control directly, but it may be the only option if the text control is not based on a standard control.
Home | Order Now | Products | Upgrades | Free Trial | Partners | About Spellex | Contact Us | Site Map | Privacy Policy
Spellex Corporation © 2012. All rights reserved