GetFullPathName

[Intel_C_Intel]

Hi
When I invoke GetFullPathName with a filename as a parameter, I always get the path returned to be the path of the executable that invokes this function and not the path of the filename. Can anyone help me on this?

Thanks
Kausik

[Intel_C_Intel]

That seems consistent with the Remarks in online help.

[Intel_C_Intel]

Hi
Then is there any function which takes a filename as a parameter and returns the complete pathname of that file?

Thanks
Kausik

[Jugoslav_Dujic]

What you want is logically impossible. It is possible that the
file with the same name exists on different drives and directories -- how could one know which of them you're looking for?

You might find the following API functions usable:

GetOpenFileName displays the "Open" dialog; the structure passed
to it contains, among other things, file title and full path name.

FindFirstFile does a search for given filename which may contain wildcards

GetCurrentDirectory returns the path to the current directory (the one specified by program shortcut. IIRC GetOpenFileName also changes the
current directory).

GetModuleFileName(NULL,... returns the path to "this" executable.

HTH

Jugoslav

[Intel_C_Intel]

Yes, in Windows 95 and Windows NT, GetOpenFileName changes the current directory, regardless of whether "Open" or "Cancel" is used to close the dialog. In Windows 98, "Open" changes the current directory; "Cancel" does not. I haven't tried 2K or ME!

[david_jones]

You could try using GETFILEINFOQQ. This would seem to allow you to do a fairly general search for a file, using the standard search order through local directory and path directories.

David Jones

[Intel_C_Intel]

I have similar observations to kausikbs with FINDFILEQQ and GETFILEINFOQQ: they only give information on and search in the current directory. Although FINDFILEQQ says in online help that it searches in directories, I have never found out how to search more than one directory at a time. I have used GETFILEINFOQQ successfully with wildcards to find all the files with particular extensions, but again, only in a single directory at a time. I do not know if the API functions behave differently, but I have not yet used any.

Bears of little brain who wrote their first FORTRAN programs in the early 60?s and have now advanced to writing QuickWin applications use the following to search for a file:

CHARACTER*80 LINE
homedir = FILE$CURDRIVE
result = GETDRIVEDIRQQ(homedir)
status = CHANGEDIRQQ(homedir(1:3))
LINE = 'dir '//FILENAME(1:LENGTH(FILENAME))//' /s/b/l/o:n >list.txt'
status = SYSTEMQQ(LINE)

[LENGTH returns the length of a string without trailing non-printing characters]

Yes, it?s that old DOS again! But it does work. It searches the current drive in all subdirectories for FILENAME and puts only the full path (in lower case and sorted alphabetically) of all copies found into list.txt at the top of the current drive. Then read the path (or paths) from list.txt, and if there is more than one copy, decide which is wanted. If all working files are kept in say Drive D, where there is better control over multiple copies than in Drive C, the problems of decision are reduced.

But I would rather not have a DOS window flashing up during the search process, and would prefer not to have to use DOS commands. Has D.A.Jones hacked it with GETFILEINFOQQ? I would welcome his posting a working example

[david_jones]

Apologies for misinformation about GETFILEINFOQQ ... this was based on a recollection of reading the descriptions of this set of routines and thinking they would be usefull, together with the very brief description in the back of the printed Language Ref.

However, I have found that FINDFILEQQ works as stated. The following is a slight mod of the example in the online help...

USE DFLIB

CHARACTER(256) pathname

INTEGER(4) pathlen

pathlen = FINDFILEQQ("gprint.bat", "PATH", pathname)

write(*,*) pathlen

WRITE (*,*) pathname

END

My PATH variable has the value

PATH=C:WINNTsystem32;C:WINNT;c:dajutil;C:WINNTSystem32WBEM

and on my system gprint.bat is in c:dajutil.

The program above yields the result

22

c:dajutilgprint.bat

when run from an arbtirary directory (in this case c:daj est estdebug ). Unfortunately, it seems that FINDFILEQQ does not take wildcards.