Re: Extending File Dialog to include unix file paths [4/4]

[Michael Lin]

Hi Steve,
Steven Edwards wrote:
--- Michael Lin <[EMAIL PROTECTED]> wrote:
--- dlls/commdlg/comdlg32.spec  
+@ stdcall UnixFSGetOpenFileNameA(ptr)
+@ stdcall UnixFSGetOpenFileN
Is there anyway for us to have these functions inlined or something rather than exported all the
time is there? The reason I ask is that being able to build applications using Wine on Windows and
Mingw helps with testing and if we building on Windows using Wine headers and link to the Wine
import libs the application will fail running the application on Windows because the Windows dll
wont export these functions.
 

If your target platform is windows, don't define the WINE_UNIX_PATHS 
flag when you compile and it will all behave
the same as before. It's only when you define WINE_UNIX_PATHS flag that 
GetOpenFileNameW() will be mapped
to UnixFSGetOpenFileNameW() for example. Else it will call the same 
function as before and shouldn't break on Windows.
WINE_UNIX_PATHS is currently not defined anywhere in WINE, so no one 
should see any difference. To see the change,
you have to define that flag in your winelib application's makefile.

You should not need any of this for a Winelib app. Office97 does this where it 
creates a 32bit
dialog with a Win16 look and its needed for backwards compatiblity only. No new 
application should
depend on this behavior and clearly not one that you have the source code to in 
Winelib. I already
broke this in Wine once. Just return GetFileDialog95W.
+        return GetFileDialog95W(ofn, SAVE_DIALOG, TRUE);
}
 

Yeah, I wasn't worried about Win16 look that's why I leave it as such. 
Might put in a FIXME later, just want to send in some
patchs before it gets too big.

Michael