• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1055
  • Last Modified:

Foxpro, Word 2003 Automation and Windows 7

I have Visual Foxpro 9 that uses word automation.  We started upgrading to Windows 7 a year ago and my app has worked fine.  We just installed a new Windows 7 pc(64-bit, Pro) just like the others, installed Word 2003 and the automation does not work.  The error says "Class Definition WORD.APPLICATION is not found."  Word is installed and works fine.  My app works fine except for this:  oWord = CREATEOBJECT("Word.Application")
0
wcsoctu
Asked:
wcsoctu
  • 3
  • 3
  • 2
  • +1
4 Solutions
 
Olaf DoschkeSoftware DeveloperCommented:
Then something is still wrong with the installation. 64bit office applications can be automated by VFP, I do this myself (Office 2010) and have seen others do it.

Bye, Olaf.
0
 
pcelbaCommented:
Office 2003 is 32 bit application.

This behavior happens when the Office installation is incomplete or simply when the Office installation does not support automation. It is not bug in your application.

Successful Office automation requires entries (class definitions) in 32 part of the Windows Registry. Full Office installation should create them for you but it seems you don't have them...

What Word 2003 version did you install? Click-to-Run installations work fine they just do not allow automation. I am not sure if Word 2003 supports this mode but I am sure you can install Word 2003 without appropriate Registry enstries.

You may try to uninstall Word and install it again from original DVD.

My recommendation: Word 2003 is not supported already you should install newer version instead.
0
 
Olaf DoschkeSoftware DeveloperCommented:
I see, Pavel. You're right there is no 64bit Office2003.

What remains true is the registration of the word.application class is missing. Could it be security/trust center hiding it despite for registered automation clients? At least there is such a thing as a Trust Center with several options and settings. It's more about what Word itself allows, eg makros or add-ins, though, not about allowing or disallowing automation of Word. It may be worth looking into anyway.

Bye, Olaf.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
CaptainCyrilCommented:
I had a client that had the same problem. He uninstalled and reinstalled Office and it worked. It sometimes happens when you have two Offices on the same computer or when you do not completely uninstall one before installing the other.
0
 
wcsoctuAuthor Commented:
Sorry for the delay, work is busy.  I uninstalled and reinstalled with no change.It is a brand new pc so there was no prior install to remove.  There is only one version of office installed.  I have scoured the net with no luck.  I changed my code to use word.basic instead of word.application and things work on my test pc as always but not on the new pc.
0
 
CaptainCyrilCommented:
Have you tried running your application as admin?
0
 
pcelbaCommented:
I don't understand...

You wrote:
1) I uninstalled and reinstalled with no change.
2) It is a brand new pc so there was no prior install to remove.

Which sounds like a nonsense...

1) If you reinstalled the software which was not there did you check Windows Registry for value "Word.Application" ?

2) If there was no Word previously installed then your command
oWord = CREATEOBJECT("Word.Application")
could not work at all.

OK, more seriously.

If the problem occurs on one computer only then start from the scratch. Format C: drive, install Windows, install Office and check if everything works (and if Registry contains necessary Class definitions).

If the problem occurs on ALL Windows 7 machines then you have to consult Microsoft. The probable answer will be "Use supported Office version" (and don't use FoxPro). Of course you may test automation from other languages not only FoxPro. In other words you have to find the working solution yourself...
0
 
wcsoctuAuthor Commented:
It was suggested that a previous install was not completely removed, thus the comment it was brand new with no prior install to remove.  It was suggested to uninstall and reinstall, thus the comment that the reinstall made no change.  Not nonsense, but perhaps not clear enough.  I did check the registry for Word.Application and it is there.

I did find the problem though.  I use impesonation to copy a file from a secured share to the local pc.  I was using automation to grab the text and display in an edit box.  After grabbing the text, I would then revert the impersonation.  Since it seemed to be permission related, I changed my code to revert the impersonation then use automation to grab the text and it works now.
0
 
CaptainCyrilCommented:
I had a problem with automation to PowerPoint. Once I launched PowerPoint from FoxPro it had no problems. If the user launch it previously there were problems. The newer Windows have funny privileges problems.
0
 
pcelbaCommented:
OK, it just means the OLE Class is in the part of the Registry specific to interactive user. In other words the Office was installed for one certain user only but not for the impersonated one. Other explanation is restricted access rights for the impersonated user.

And yes, there are many undocummented settings which could affect this behavior in Windows.  The impersonated user does not see printers sometimes etc.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now