Albrecht Schlosser wrote: > I only took a short look at it (a little grep and such), but it > seemed so. I'm thinking of making a single function, say > fl_OleInitialize(), that keeps track if it has been called already > (instead of the different places in the rest of the code), and then > the destructor could just ask the flag if it should do the > OleUninitialize call. Or so... > > Some of the different calls seem to be due to the (previous > external) Fl_Native_File_Chooser that might have missed the > integration with this MS-specific Initialize and Uninitialize > (what a word! ;-) stuff.
I haven't had (will not have) time to look in any great detail, but it seems that maybe we only call OleInitialize in two places (Fl_Native_File_Chooser and Flwin32) and we call OleUninitialize in one place (Fl.cxx). Also, Fl_win32.cxx may call CoInitialize if it has not already called OleInitialize - though looking briefly at this I could not see how it could ever get to the code that calls CoInitialize without having first executed the part that does OleInitialize, so that may be redundant code... If so we could remove it and make things a bit simpler. Now, in Fl.cxx, the Fl_Win32_At_Exit code unconditionally calls OleUninitialize (and nobody ever calls CoUninitialize) so: We simplify Fl_win32.cxx to only use OleInitialize (not CoInitialize) and add a mechanism so that both Fl_win32 and Fl_Native_File_Chooser will flag up that they have loaded OleInitialize (and not load it again) and make sure that Fl.cxx only calls OleUninitialize if that flag is set... Something like that? Also - this is all for fltk-1.3. I assume fltk-1.1.10 has the same bug (though it does not have Fl_Native_File_Chooser I think?) and I guess we can't fix it there since the fltk-1.1 series is frozen now. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
