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