Spell Checker with Access 97 Run-time
Derek Elliot
run-time version of Access is loaded on the machine in question. If the
machine has a standard version of Office on it already it works OK. What
needs to be added to the Run-time installation to get this to work.
Alan Dods
Sorry, you're not allowed to distribute the spell checker with runtime
apps. This is from KB article Q179318 - ACC97: How to Simulate Office
Features in an ODE Application
http://support.microsoft.com/support/kb/articles/Q179/3/18.ASP?LN=EN-US&SD=gn&FR=0
QUOTE
Some of the features in the retail version of Microsoft Access are not
available for run-time
applications that you create using the Microsoft Office 97
Developer Edition Tools Setup wizard.
For example, you are not able to redistribute the spelling checker
files or the Microsoft Access
wizards with your run-time application. However, there are ways in
which you can simulate the
features in Microsoft Office in a run-time application.
MORE INFORMATION
The following list describes features that are disabled in custom
applications that you create
using the Setup wizard and how you can simulate those features.
Spelling Checker Functionality
Issue
You want to add spelling checker functionality to your run-time
application.
Solution
You must write a procedure to run the installed spelling checker
that is already on your user's
computer or look for a 3rd party add-on that does spell checking.
If Microsoft Word 97 is
installed on your user's computer, you can write a procedure for a
command button's OnClick
property. For example, the following sample code is attached to the
OnClick property of a
command button on the Employees form. When clicked, it will check
the spelling of the
contents of the Notes field:
Private Sub Command0_Click()
Me!Notes.SetFocus
Me!Notes.SelStart = 0
Me!Notes.SelLength = Len(Me!Notes)
RunCommand acCmdSpelling
End Sub
ENDQUOTE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you need a third party speller, try
http://www.fmsinc.com/products/speller/index.html but I think it's US
English only.
Even on systems where the Office Spellchecker is already installed,
there can be problems, at least I had problems with UK English vs. US
English. I don't know if MS provides an Australian English checker.
Anyway, here are some old posts of mine from August 98, which might
prove helpful if you do run into trouble. They made sense to me at
the time, but they seem a litle confused now.
============== Post 1 ===========================
I had some trouble getting this to work. I have a machine with Word97
installed. I installed an Access Runtime app with buttons on forms
that do the above.
When I tried to use them, I got the error:
"Appname can't start the spelling checker because it isn't installed"
I had mssp232.dll and mssp2_en.lex in Program Files\Common
Files\Microsoft Shared\Proof
and the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Proofing
Tools\Spelling\2057\Normal
containing the correct Dictionary and Engine strings
What I did was to clone that key to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Proofing
Tools\Spelling\1033\Normal
(I noticed I had both these on my main machine which has Office 97
Professional Installed)
Then it worked. I just had to go into Spelling options from within
Access Runtime to change the language from US to UK.
Does anyone know what these 2057 / 1033 values actually mean?
Should I add the 1033 keys in my custom setup, just in case they
aren't there on user machines that have Word97 installed?
============== Post 2 ==========================
More experimentation reveals that I can now delete the 1033 version of
the key and it's still happy. In spelling options I have only
English available now (when both keys are there, I have American
English and English)
So, I understand the problem. The Access Runtime by default was set
for US English. There was no key for US English (1033) in the
Registry (even though the dictionary files are the same), so it
wouldn't work, because it didn't know where to look for the files.
Adding the 1033 key allows me to get it working, then I can change the
language option in the spell checker to UK English (presumably this
modifes another registry key). Once I've done that, the 1033 key is
redundant and it uses 2057.
So the question becomes, how do I get the Access Runtime Installation
to default to UK English dictionary?
================ Post 3 =========================
And the answer to that appears to be to add the following registry key
using the setup wizard:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\8.0\Access\Speller
and set the numerical value:
"Language ID" to 2057 (0x0000089 hex)
Hey presto - run the new app and the spellchecker comes up. (I've
tested this with the original registry settings - only the 2057 key
listed under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared
Tools\ProofingTools\Spelling)
The rest of the values for the new registry key (Custom.dic, always
suggest etc) get filled in if the user chooses Spelling Options and
changes something.
============= Postscript=====================
That solution worked at the time. Later on I had to start using a
User Profile to get the right helpfile, so then I moved the Speller
key to $(Machine's Software Key for App)
(Profile settings take precedence over MS Access Settings, MS Access
Settings over Jet settings - ODE setup wizard help topic (Registry,
Adding keys in Setup Wizard -> Create a User Profile). N.B. if you
aren't into this already and you get into it, read KB article Q164256
- ODE97: ODE Setup Wizard Creates Unexpected Registry
Keys. The helpfile makes it sound as though you have to create the
profile entry in:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Access Runtime\8.0\Profiles
(at least it did to me) but in fact this is created automatically.
==============================================
Sorry this is such a rambling reply. Hope some of it is helpful.
Good luck
Alan
(posted and emailed)