>>I hate the "trap error" routine for trying to make a determination such as this. I'd use the registry class and check for the existence of the Word.Application key under HKEY_CLASSES_ROOT. Then again, that's just me.
>
>Works for me. I was thinking more on the level of using CLSIDFromProgID() in C++. If that function yacks on me, I know I won't be calling CoCreateInstance() on that particular ProgID. My suggestion works along that same line of thought.
>
>OTOH, I guess CLSIDFromProgID() is really just checking the registry anyway, so if there were just one "right" answer, yours is probably closer. Then again, why not just call CLSIDFromProgID(), check the result, and eliminate the middleman? :-)

I'm not sure. I just tried it with Word.Application and got CO_E_CLASSSTRING (0x800401F3) back. Didn't check the value in the return string (which was originally an empty string when sent, but came back with something in it. The registry class's IsKey() returns true, the key exists, there's an CLSID with it, Word 2000 is installed, but the return value isn't S_OK. I'm clueless as to what's going on. FWIW, here's the code:

DECLARE INTEGER CLSIDFromProgID IN ole32;
  STRING @lpszProgID, STRING @pclsid
lcCLSID = space(39)
lcprogID = "Word.Application"
lnresult = CLSIDFromProgID(@lcProgID, @lcCLSID) && Returns 0x800401F3
? lcCLSID && Junk or is it the key?
SET CLASSLIB TO REGISTRY ADDITIVE
oReg = CREATEOBJECT('Registry')
? oReg.IsKey(lcProgID)

See anything wrong?