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

[Steven Edwards]

Hi Michael,

I really like the idea of trying to tie the apps in better for users of Winelib applications but I
have a few problems. (I should have spoken up when the first of the Unixfs stuff was going in to
shell32 because I feel it should have been a shellext outsite of shell32 but now I am off the
subject)

--- Michael Lin  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.

+BOOL WINAPI UnixFSGetSaveFileNameW(
+	LPOPENFILENAMEW ofn) /* [in/out] address of init structure */
+{
+    BOOL win16look = FALSE;
+
+    if (ofn->Flags & (OFN_ALLOWMULTISELECT|OFN_ENABLEHOOK|OFN_ENABLETEMPLATE))
+        win16look = (ofn->Flags & OFN_EXPLORER) ? FALSE : TRUE;
+
+    if (win16look)
+        return GetFileName31W(ofn, SAVE_DIALOG);
+    else

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);
 }

Thanks
Steven

Discover Yahoo! 
Stay in touch with email, IM, photo sharing and more. Check it out! 
http://discover.yahoo.com/stayintouch.html

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

[Michael Lin]

Hi Steve,

Steven Edwards wrote:
> --- Michael Lin  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