No problem -- actually already knew that it was somewhat moot because the function in question was built into VFP (at least as of v6.0). Mainly provided the info as I'd run into similar puzzling situation where DLL/FLL wasn't working (as noted in my message that it was because the "wrong" one was "closer" in the search path than the "correct" one) and thought that this info might be of use to someone else.
With regards to AFILEGETVERSION() -- was most certainly glad when I noticed that it was available in VFP. Back in the FPW days the only way I could get that functionality was to add similar sort of function into a DLL/FLL. This meant either adding an additional DLL/FLL (adding yet another item to worry about), or add to existing one (which would require that you check revision info to make sure it was available... Fortunately for me, the DLL already had something along the lines of reporting revision info that I can check to make sure it had function that I could use to check revision info for DLL/EXE in general).

>Thanks Naoto
>
>I'll look into this just for interest, but I'm only using FOXTOOLS for GetFileVersion to check the EXE version, didn't realise that there's now a command that's part of VFP called AGetFileVersion thats does the same thing, so that makes FOXTOOLS redundant for me now and solves my problem.
>
>>Have you checked where else you've got the FLL file -- especialy in directories listed in the PATH? I'd had many a head-scraching experience with the "wrong" DLL being loaded because of this. Another weird thing that could happen is when you've got the DOS APPEND command in effect (or anything of similar nature -- basically where PATH is used for executables, APPEND is for data files). When attached to Novell, the behavior was such that mapped drives behave as if you've got a APPEND in affect (so you may be surprised when you try opening a file that doesn't exist in the current directory, that a file on another drive with the same name would get opened).