>>>I learned to never trust relattive paths when it comes to automation.
>>>The application have one MS Office has others :-)
>>>That is why i always use FULLPATH() :-)

The only reason relative paths ever worked was that they weren't exactly relative (Srđan's begins with a backslash, so it's only relative to disk, but not to current folder) and that the default installations of windowses put everything on c: drive. All eggs in the same basket. Now with power users, who know how little reinforced concrete holds these straw walls start putting their stuff on other partitions and voila - it's not necessarily on C:, your code breaks.

The paths used by a COM object may be anything, depending on who owns the proces which launches it; I've seen various combinations of %appdata% or simply c:\windows\system32 as the current directory. Learned that in a fox COM object, _vfp.ServerName is my lighthouse and navigated from there :). Also that anything COM launched from fox may CD on you (save current folder, restore on exit - one such offender is an IE window if it prints) and that id doesn't know where it is, all filenames must be full paths.

Makes sense, though, it's a foreign object, executing in its own space, inherits nothing of the caller's environment, knows only the parameters passed. So the parameters better be good.

>I prefer SYS(2000)

Haven't used that one since 1989 :). At least not directly - I guess aDir() uses it internally.