NewsForumsCodeLogsGallerySpecsSearch

Win32:RequestFile and RequestDir

BlitzMax Forums/BlitzMax Programming/Win32:RequestFile and RequestDir

Oddball(Posted 2006) [#1]
On win32 systems both RequestFile and RequestDir return directory paths with backslashes "\" instead of forward slashes "/" like all the other file and directory functions.
' requestfile.bmx

filter$="Image Files:png,jpg,bmp;Text Files:txt;All Files:*"
filename$=RequestFile( "Select graphic file to open",filter$ )

Print filename
Having a quick look at the source I think this can be solved by a call to FixPath.


marksibly(Posted 2006) [#2]
Hi,

You can legally use either / or \ in paths on the win32 platform so not sure if this is a 'bug'.


Oddball(Posted 2006) [#3]
That is true but if I'm comparing a string returned from the function CurrentDir and a string returned from RequestDir they will always be different unless I convert all the slashes in one of them. I just expected all the file functions to return paths that use the same convention.


marksibly(Posted 2006) [#4]
Good point. Thinking...


ziggy(Posted 2006) [#5]
What about a 'file comparison' function (getting two string as parameters, with a comparable filenames.
This function could process all the / and \ and even all the ..\ and .\ to get a simple path of each file, even convert the strings to lowercase or uppercase on win and mac, before comparing them, and return true or false if the given strings are 'pointing' to the same file).
Can this could be a good solution for this platform releated issue?


marksibly(Posted 2006) [#6]

What about a 'file comparison' function (getting two string as parameters, with a comparable filenames.
This function could process all the / and \ and even all the ..\ and .\ to get a simple path of each file, even convert the strings to lowercase or uppercase on win and mac, before comparing them, and return true or false if the given
strings are 'pointing' to the same file).


Well, there's already 'RealPath' in there which does most of this - eg: RealPath(x)=RealPath(y). This could easily be wrapped in a ComparePaths().

I think this RealPath/ComparePaths approach is probably the safest, instead of trying to coerce all file names at 'source' into a common format. This means it wont matter if the path is win32/unix/absolute/relative or whatever.

I will have a closer look at RealPath() and make sure it's up to the job!