Mike Hearn wrote:
On Tue, 04 Jan 2005 11:22:00 -0500, Dan Notestein wrote:
Btw, if anyone is interested we also have another module which can be used to convert the windows-style drive letters returned by the common dialogs into unix-style paths (if you want to use these paths will "normal" file i/o functions such as C++ stream i/o).
Isn't that what wine_get_unix_file_name does?
I was responsible for this bit of hackery, so I'll try to explain. The patch Dan sent in before only changes how the common dialogs display the filenames, it doesn't change how they deal with them internally. The GetOpenFileName() function returns a structure containing the filenames the user selected. Since the patch only changed the appearance of the dialog, GetOpenFileName() would still report that the user had opened the file "e:\foo\bar" instead of "/tmp/foo/bar". This may or may not be what you want. If you're porting a windows application that passes these filenames to Win32 functions like OpenFile(), it will work. But if you're passing those filenames to native unix functions like fopen() (or to c++ iostreams, which in turn call fopen()), you'll have problems.
The module Dan was referring to above implements wrappers around the common dialog box routines that return filenames. It just converts the filenames that the real routine returns to us to unix-style names by calling wine_get_unix_file_name, and properly modifying the structure that gets returned. It was non-invasive, and works independently of the patch that affects the appearance of the dialogs.
You could make a case that the appearance of the dialogs should be controlled by a registry key, but the type of filenames they return must be known by the application for it to function properly.
Eric