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

[Michael Lin]

Hi Steve,

Steven Edwards wrote:

>--- Michael Lin <mlin at corvu.com.au> 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