How to enable the spellchecker in a protected document
Article contributed Dave Rado, Bill Coan Bill Coan, Astrid Zeelenberg, Dan Monk and Geoff Whitfield
Unfortunately, Word's protection feature disables a huge number of important functions, even if you only protect a single section of a document. As well as the spellchecker, many of the items on the View, Insert, Format, Tools and Table menus are disabled, as well as most items on the Drawing, Database, Visual Basic and Picture toolbars.
The most important of these is probably the spellchecker, which you can re-enable as follows. In your Forms template, (which you should leave unprotected for now):
1. |
Create a macro, and paste the following code in, first deleting anything in the code module that Microsoft inserted automatically. Note: you may want to modify the line which says Selection.LanguageID = wdEnglishUS to your own language). Option Explicit Private Sub
CheckProtectedSection(oSection As Section) Private Sub
TurnNoProofingOff(FmFld As FormField) Private Sub
Word97TableBugWorkaround(FmFld As FormField) Notes:The reason for the TurnNoProofingOff() subroutine is that Word 2000 treats No Proofing as a separate property. That is, you can set the No Proofing property to true or false without losing the Language setting. In Word 97, No Proofing was a language setting, so there was no way to have a selection of text marked both as No Proofing and at the same time as, say, wdEnglishUS. But in Word 2000 you can do this. It's really a great improvement but a bit of an extra pain for developers trying to meet the needs of both versions of Word. The Word97TableBugWorkaround macro is not required if all of your users are using Word 2000 or higher, or, if they have all installed the so-called Word 97 “Leap Year Fix” (or later patches). In the original release of Word 97, if you spellchecked a form field within a table, and if the form field contained multiple paragraphs, Word would crash. This bug was fixed by the so-called Word 97 “Leap Year Fix” (a free upgrade which fixed well over 40 bugs). The Word97TableBugWorkaround subroutine (above) works by converting the form field to plain text, spellchecking the text, using Undo to reinstate the formfield, and putting the spellchecked result into the reinstated field.. The subroutine is only invoked if you are using Word 97, if the formfield is in a table, and if the formfield contains more than one paragraph, so leaving it in won't actually do any harm even if you are using a later version of Word. The reason that, depending on the user's settings, the macro runs the
spelling and grammar checker if the document is not protected, but only
runs the spellchecker, even in unprotected sections, if the document is
protected for forms, is because of a bug with the CheckGrammar method. The
CheckGrammar method works properly with the document object, (oDoc.CheckGrammar
checks both spelling and grammar), but it does not work properly with
Range objects (for instance, oSection.Range.CheckGrammar
checks the grammar in the section but does not check the spelling!) |
||||
2. |
If your form is password protected, and you don't want the user to be asked for the password to reprotect it, you have to put the password in your code:
oDoc.Unprotect Password:="Password"
And:
oDoc.Protect Type:=wdAllowOnlyFormFields, NoReset:=True, _
If you want to ensure that users can't possibly see the password, you can
also password protect your code (in the VBE, select Tools + Properties, and then
select the protection tab).
|
||||
3. |
To make it seamless to the user, you could assign your macro to a toolbar button, and to a menu button on the Tools menu , replacing the existing spellchecking buttons with yours. You could also copy the button images from the Microsoft buttons to yours,
to make it
completely seamless to the user. |
||||
4. |
Because of the way in which Word's spellcheck dialog works, if any of your formfields are surrounded by (protected) text, some of this text may be displayed in the dialog alongside a spelling error – thus allowing the user to modify protected text ““through the back door”. The best way to prevent this is to design your forms such that each formfield is in its own table cell; and the problem will then never arise. In my experience, with a little ingenuity, it is always possible to design your forms in this way. Failing that, the only ways of completely preventing this problem from arising would either be to:
Both the above solutions are beyond the scope of this site; and in any case, will not be necessary if your formfields are in their own table cells. |