>Use the run command as follows:
>run /n1 "C:\Program Files\Internet Explorer\IEXPLORE.EXE" "www.anthology.com"
>

Bad choice, for several reasons. First, he wanted to launch the default browser; this would launch Internet Explorer if it worked. Second, IE doesn't have to be located where you think; on my system, it happens to reside at F:\Program Files\Internet Explorer\IEXPLORE.EXE, because my system volume happens to be the F: drive on this machine; you're not required to accept the default install location IAC. THis is a major issue when running in an environment like WTS. Third, RUN commits you to starting a new instance of IE; this may not be necessary if the browser is already running.

Using ShellExecute(), either via the FFC class, or by direct invocation of the API call, addresses all of these issues directly - it relies on the information in the registry to invoke the proper app, from the proper location, with the proper command line options or IPC mechanisms for the current user and system configuration. The logic behind the file association in the registry is to relieve us of the responsibility to allow for variations in setup or user preference on a system by system basis. There are arguments in favor of various COM approaches - Wscript.Shell could allow you to wait on the instance of IE to close before continuing; on my system:

oShell = CREATEOBJ('Wscript.Shell')
oShell.Run('"F:\PROGRAM FILES\INTERNET EXPLORER\IEXPLORE.EXE" www.levelextreme.com',,.t.)

waits on the new instance of IE to close before continuing (you can't use the DDE or ShellExecute() invocation to do this, because it doesn't always start a new instance of IE).

IOW, RUN is the least capable of the available options, and hard-coding the path to the executable is just asking for trouble where it can be avoided easily.

>
>>>Is there some code somewhere I can examine that
>>>will let VFP 6.0 launch the default browser and go to
>>>a web-site?