>>>Bret,
>>>
>>>ShellExecute will return an error condition flag if there is no association for .htm files. The code in the dfwinapi classlib of the spyin.zip file has all the details.
>>>
>>>>Do you know of a good class that is available to enter a key and it tell me if the registry has that key registered?
>>
>>Your class is a great tool and I appreciate your time. My question involves knowing ahead of your shell.execute() method whether a .TAP extension is valid and can be handled by the system. Post error processing is ok, but in this instance I would like to know that the extension can be handled before hand.
>>Any help would be appreciated.
>
>Hi Brett,
>
>Try the FindExecutable function in the SHELL32. Here's the declaration:

>DECLARE INTEGER FindExecutable IN Shell32;
>  STRING @lpfile, STRING @lpdirectory, STRING @lpbuffer
>* lcfile is the file you want to find the executable for
>lcdir = JUSTPATH(lcfile)
>lcbuffer = SPACE(260)
>lnresult = FindExecutable(@lcfile, @lcdir, @lcbuffer)
>IF lnresult > 31
>  lnpt = AT(CHR(0), lcbuffer)
>  lcexecutable = LEFT(lcbuffer, lnpt - 1)
>ENDIF

>hth,

The FindExecutable function is supposed to retrieve the fully qualified path to the executable (.exe) file associated with the specified file name. For example, the following call to FindExecutable() should return the path to Winword.exe:


FindExecutable ("C:\\README.DOC", NULL, szBuffer);

Assuming Winword.exe is currently in the C:\Msoffice\Winword directory, the function, upon return, should fill szBuffer with the string C:\Msoffice\Winword\Winword.Exe.
However, when you use FindExecutable() on a file whose associated application is in a directory that has a long file name (LFN) that includes a space, the function truncates the string up at the first space. Going back to the previous code example, if Winword.exe is located in the C:\Program Files\My Accessories directory, the function incorrectly returns the truncated string C:\Program instead of the following expected string:


C:\Program Files\My Accessories\Winword.Exe

CAUSE
File associations are stored in the registry under HKEY_CLASS_ROOT, where the executable name is actually stored under the key


HKEY_CLASSES_ROOT\\shell\open\command =

By design, long file names stored in the registry should be enclosed in quotation marks. Otherwise, the system is made to treat the rest of the characters following the space as arguments.
In the example, the path to WinWord.Exe should be stored in the registry as:


HKEY_CLASSES_ROOT\Word.Document.6\shell\open\command =
"C:\Program Files\My Accessories\Winword.Exe" /n

which does causes FindExecutable to return the expected string.
Note that this problem does not occur when the short path name is stored in the registry, instead of the long file name. Again, taking the same example to WinWord.exe, this should not be a problem if the short path name "C:\Progra~1\MYACCE~1\WINWORD.EXE" is stored in the registry instead of the LFN version.



WORKAROUND
In some situations, applications do not have control over what gets stored in the registry. It may be the associated application's setup program that wrote the incorrect LFN string (without quotation marks) to the registry. Any application that would then call FindExecutable() on this associated application will run into this problem.

One workaround to this problem might be to parse the string returned and replace the \0 character with a space. Stepping through a debugger, after FindExecutable() returns, you will quickly find that although the space has been replaced with the NULL character (\0), the rest of the string is left intact, so simply reverting the \0 character back to a space gives the expected string.

Just thought you would like to know, I found this out just today when I ran my code.

Bret Hobbs

"We'd have been called juvenile delinquents only our neighborhood couldn't afford a sociologist." Bob Hope