Hi Ed,

Thanks for the reply. I looked in HKEY_CLASSES_ROOT and found .doc but it didn't have the \shell\open like some of the other ones. It did have in the default Word.Document.8. Am I checking the correct registry entry? Would I just check to see if a \shell\open exists if Word is not the default data?

Thanks for your help



>>>>>>>>>>>>>>>>>>
>>Why not simply check the registry for the appropriate key?
>>>>>>>>>>>>>>>>>>
>>
>>IMO, because some genius may have 'deleted' Word or somehow screwed it up w/o properly unistalling it, i.e. the existence of a registry key does not assure it will work.
>
>By the same argument, being able to instantiate Word.Application isn't an absolute guarentee of functionality, either; I can think of (translates to: have seen people find) plenty of things that can screw up Word that won't appear when Word.Application first instances.
>
>IAC, the time to check for a registry key's presense compared to the time for CREATEOBJ() or NEWOBJECT() to fail is miniscule, so it makes sense to me at least to check for the registry key before even attempting to instance the object.
>
>I'd be more inclined to trust the registry information for Word 2K; the Windows Installer does a pretty outstanding job of protecting and restoring 'accidental' removals of some or all Word components, especailly under Windows 2000. I probably will need to check the registry for something; checking the registry can prepare you for other things like finding a different server for the RTF and DOC file extensions (eg. if Word isn't present, check to see who owns the Open action for these things.) Since the general work needed to get ready to check registry keys probably is useful even without the need to check for Word, and error handling needs to be set up whether Word.Application is creatable or not, having the code for both seems prudent.