Sentry Spelling Checker Engine - Support

Home Site index Contact us Catalog Shopping Cart Products Support Search

You are here: Home > Support > Sentry Spelling Checker Engine > Problems checking text controls

Problems checking text controls

Product: Sentry Spelling Checker Engine Windows SDK

Problems:

1. The Sentry DLL will check only the selected text, regardless of the value of the "selectedOnly" parameter passed to SSCE_CheckCtrlDlg.

2. The Sentry DLL fails to find any misspelled words in the control's text, even though I am sure there are at least one.

3. When misspelled words are corrected, the 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.

4. When misspelled words are corrected, the text control is not changed.

5. 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 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 Sentry DLL.

The 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 Sentry DLL knows the class names of the standard controls, but may not recognize the window class names of superclassed controls. If the 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 Sentry DLL may not be the right ones.

If you encounter problems similar to the ones noted above, it may help to tell the 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 Sentry Windows API" / "Checking Controls Interactively" / "Checking third-party controls" in the 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.

Another solution is to treat the control as a "third party" control and follow the approach used in the "Check 3rd party" demo in the Sentry example programs. (See Using SSCE_CheckCtrlDlg with a third-party edit control for more information).