Spell Check Problem... (1 Viewer)

[MLUCKHAM]

What is the late binding option for DoCmd.RunCommand acCmdSpelling?

I have a Access Runtime system which is being moved to machines with Office 2010, Office 2013, Office 2007 etc

The system currently has a reference to Microsoft Office 14.0 Object Libary which means that when installed on a computer with Office 2010 running it can use the Office spell check.

What I would like to use is late binding so I can connect to different versions of Office, however I have no idea what to late bind too (Office.Something) and then how to invoice the same Spell Check command as DoCmd. is not going to cut the mustard...

 

[vbaInet]

I don't follow. Whatever version of Access the app is opened with will use the Spelling dictionary installed with that version.

 

[MLUCKHAM]

Not with Access Runtime. Proofing tools (such as spell check) are part of Microsoft Office. If you want them to work on machine that does not have Full Access (e.g. You need to use Access Runtime), but they have office installed, then you need to reference the office DLL. However, early binding causes some challenges with different versions of office...

 

[vbaInet]

I'm trying to understand what you're asking and your current setup. You've got an accdr or an accde file? And you have full versions of Access installed or the runtime versions installed?

 

[MLUCKHAM]

This is a Access system that I have developed. It is part of a larger product which is sold to clients. I release the system using Access 2010 runtime. This allows me to distribute the system without the end user having to have purchased Office professional and have Access installed.

Some of my clients do not have any office installed. They just have Windows 7 or Windows 8. For those clients the system uses a spell check that I have written.

However for some of my clients they do use Office. In my development environment I have Office Professional 2010 installed so the system I have developed references the Office 14 object library. If my client has Office 2010 installed (regardless if they have Access) I can use the office spell check through the Access Runtime. This spell check is better than the one I have knocked up!

My issue is that some of my clients have Office 2007 installed, or office 2013 installed. Early binding to a specific office 14 object library (which is office 2010) does not help these people and they have to use my custom spell check.

If I could use late binding then I could do a quick registry check, work out which version of office they have installed, late bind to that dll and then call the Microsoft spell check.

Unfortunately proofing tools are not released separately by Microsoft. They come with Office so I am not able to roll them out with my system.

 

[vbaInet]

Ok, I follow. I don't think that a reference to the Office Object Library holds the Spell Checker anyway, because with that reference unchecked, the spell checker still works. With that said, further investigation is required to determine exactly how the spell checker is referenced.

I still don't know whether it's an accde or an accdr file?

You've got an accdr or an accde file?

For further reading, have a look at this:
https://support.microsoft.com/en-us/kb/262605/en-us

 

[MLUCKHAM]

The spell checker is referenced through the office object model as I used it now, however with full blown Access the proofing tools are referenced within the Access environment. but as I am using early binding I have to reference a specific object. I am using an accdb file through Access Runtime 2010 32 bit. I think I may have a solution. I have found the proofing tools as a free download for Office 2013. I will try and port my system to Access runtime 2013. If it works I could bundle the proofing tools with my install.

 

[vbaInet]

But like I highlighted, the Spell Checker works regardless of whether the Office 14 object library is referenced or not. This is an indication that it's not called elsewhere.

 

[MLUCKHAM]

To be honest my post was not to discuss the mechanism. I have had to do the leg work and I know how the spell checker is called. My post was about the early and late binding options for the office object model. By all means do the same analysis, but take my word for it, in Access runtime you need to reference the office object mode for proofing tools to work.

 

[vbaInet]

You're missing my point. I created accde and accdr files without the reference to that library and the spell checker still works. As you know, a reference to a library merely exposes the classes and functions that are included in that interface, so that that it can be used in code. The spell checker cannot be instantiated from the Office library, but it can be called using one of the RunCommand constants. My point is, Access is referencing the spell checker elsewhere, perhaps directly calling the DLL and that reference could be somewhere in a registry key. You get my point now?

 

[MLUCKHAM]

That is not my experience. When I was working on this component I had a fresh Windows 7 machine with Office 2010 installed (but no Access). I installed Access Runtime. When I tried the DB without the office reference the spell check did not load. With the reference it does load. In fact if you press F2 and explore the object model of the Office object you will see the command bars object (which is what the Docmd.Runcommand is calling). I will see that if I can get late binding working ...

 

[vbaInet]

I did it differently. I wasn't opening the db using the runtime, I was using the full version to open the accde and accdr.

It's been quite some time I did anything Access and if you could add the reference (i.e. Access.References.AddFromFile/AddFromGUID) it would have helped your cause. But obviously it won't work with the runtime environment.

I'll see what class name can be used to late bind to Office and let you know.

 

[vbaInet]

In the meantime, is your application accde or accdr? I think I've asked this already but got no response.