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

+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