Extending File Dialog to include unix file paths [4/4]
mlin at corvu.com.au
Thu May 12 23:58:21 CDT 2005
Steven Edwards wrote:
>--- Michael Lin <mlin at corvu.com.au> wrote:
>+@ 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.
More information about the wine-devel