SpellText and SpellEditor both need to have the following files copied to your Windows System folder:

ChadoSpellText.ocx (or ChadoSpellEditor.ocx)
ChadoSpell.DLL
MSVBVM60.DLL
Comcat.dll
Asycfilt.dll
Stdole2.tlb
Olepro32.dll
Oleaut32.dll

Note: The last six files listed are Microsoft support files, and may already be installed on your target machine.  It's important to install the latest versions of these files.  If you are importing or exporting HTML, you must have IE version 4 or greater installed.

Nine times out of ten, this is because ChadoSpell.dll isn't located under the Windows directory.  ChadoSpell.dll is used by both SpellText, SpellEditor and SpellServer during the checking.  It isn't a COM object, so it doesn't need to be registered via REGSVR32, but it does need to be located in the Windows or Windows\System32 directory.

This problem occasionally happens for both SpellText and SpellEditor.  The solution is to completely uninstall the evaluation version of your product first, then delete all copies of ChadoSpellText.ocx for SpellText, or ChadoSpellEditor.ocx for SpellEditor, reboot, and then install the retail version.

In Visual Studio.NET, bring up the Toolbox, click on the Components tab, right-click and choose "Customize Toolbox...".  (Please note that in VS.NET 2005, you'll have to choose the "Choose Toolbox Items..." menu item from the Tools menu.)  Fill in the check box next to either "Chado SpellText" or "Chado SpellEditor", and the control will show up in your toolbox, and can be used as normal.

Occasionally, you may see a problem when you try to drag and drop SpellEditor or SpellText onto a form.  The error message may say something like "Failed to import ActiveX control".  In this case, we've found it to be helpful to go to the OBJ folder (which is a subfolder that .NET creates in your application folder), and looking in the next level of folders (like OBJ\DEBUG, for example), delete any Interop DLL files that .NET may have created.  Usually, .NET will recreate those Interop files.  At this point, try dragging and dropping SpellEditor or SpellText onto the form again - it should work fine.

The problem arises because when VS.NET creates the Interop DLLs for SpellEditor or SpellText, it doesn't strongly name them.  However, if your main assembly is strongly named, then all other assemblies that it uses must also be strongly named.  See Microsoft Q313666 for more details.

The solution is to manually recreate the Interop DLLs for either SpellText or SpellEditor using the AXIMP command, with the /KEYFILE parameter. The steps are as follows:

First, create a keyfile using SN -K <KeyFileName>.

Then run AXIMP ChadoSpellEditor.ocx /keyfile:<KeyFileName> to generate new signed Interop files.

After that, just copy the newly generated interop files onto the VS.NET-generated Interop files (located in the OBJ folder of your project), replacing the VS.NET-generated ones.  If you haven't added the control to your project yet, instead of overwriting, just add a reference to the newly-created Interop files and use the control as normal.

If you are seeing the red X instead of the SpellText control, this is due to Microsoft's recent security patch (released in April of 2006).

To fix this bug, remove the "#ver=" part of your OBJECT tag (including the version number, which is something like "2,7,0,1") that comes after the clsid portion of the tag.  This seems to solve the problem.

This problem is caused by some of the security features that are part of Windows.  To solve it, go into Internet Explorer 7's Tool → Internet Options → Advanced menu.  Scroll down to the Security section, and check the box labeled "Allow active content to run in files on My Computer".

If you don't have IE 7 installed on your computer, try the following:

Using RegEdit, browse to the following registry branch:

HKCU\Software\Microsoft\Internet Explorer\
		Main\FeatureControl\FEATURE_LOCALMACHINE_LOCKDOWN

Create a new REG_DWORD value named iexplore.exe and set it to 0.  This will allow active content to be run from a file on your computer, which is functionality needed by SpellEditor.

Due to built-in security settings for Internet Explorer, you cannot assign to the .TextHTML property from within a web page using Javascript.  You can assign to the .Text and .TextRTF properties without a problem.

If the control is visible, but inactive, this is a direct result of Microsoft's new security approach, which was introduced with a patch in April, 2006.  You can activate the control by clicking on it, but with SpellEditor, the toolbar may remain grayed out.

There is a Microsoft article that describes how to programmatically activate the control.  It's found at: http://msdn.microsoft.com/workshop/author/dhtml/overview/activating_activex.asp.

To force the toolbar to become active (either before or after activating the control itself), use Javascript to hide, and then show the toolbar:

document.all.SpellEditor.object.ShowToolBar = false;
document.all.SpellEditor.object.ShowToolBar = true;

The problem seems to be related to "Data Execution Protection" (DEP).  Try setting DEP on for essential Windows programs and services only.

To set DEP, go into the Control Panel, then System, then Advanced, then click on "Settings" under Performance, then select the Data Execution Protection tab.  Choose "Turn on DEP for essential Windows programs and services only".

There is a workaround for this problem.  Add the following code to your document.onkeydown event handler code (or create such code if it doesn't currently exist):

if (window.event.ctrlKey && 
    window.event.keyCode==67 && 
    window.event.srcElement.id=="SpellEditorObjectName")
        window.event.keyCode = 3;

After setting the Printer.Orientation to 2 (landscape), be sure to issue a DoEvents call before calling SpellEditor.PrintSelection.

If you click on the bullet toolbar button repeatedly, it will cycle through all of the numbering styles that are available.

The best solution seems to be to reset the width of the control to a new value.  This resize forces VFP to redraw the control.

This problem occurs because the SpellText or SpellEditor Control is initializing before the container.  To solve it, add some code in the Form's Init event to set focus to the SpellText or SpellEditor control.

When coding in Visual C++, there seems to be a problem with the AllowTabs property.  As a workaround, please use the following technique:

void CChadoTestDlg::OnKeyUpSpelleditor1
		 (short FAR* KeyCode, short FAR* Shift)
{
     if(*KeyCode == VK_TAB && !*Shift)
     {
          m_spellEditor.SetSelText("\t");
          m_spellEditor.SetSelStart(
             m_spellEditor.GetSelStart()+1);
     }
}

If you use a third-party tab control, the problems go away.  Try using the one at http://www.codeproject.com/cs/miscctrl/magictabcontrol.asp instead of the standard Microsoft tab control.

There is no problem using SpellEditor or SpellText with the tab control in VS.NET 2005.  The problem only occurs with VS.NET 2002.

If you compile the DB into a MDE file, the problem with be resolved.

One possible solution is as follows:

First, make sure that the form's KeyPreview property is set to Yes.  Also, the SpellText or SpellEditor control must not be the last tab item on your form.  Add the following code:

In Form Keydown event:

If KeyCode = vbKeyReturn Then
  If Screen.ActiveControl.Name = "SpellText" Then
     bNewLine = True
  End If
End If

In the SpellText LosingFocus event:

If bNewLine Then
  bNewLine = False
  SpellText.Object.SetFocusToMe
  SpellText.Object.SelText = Chr$(13) & Chr$(10)
End If

Try different approaches with the Javascript events.  The following event style may help:

<script language=javascript
   for=spelltextobjectid event=spelltextevent>