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