May thanks for the insight. I Really would appreciate if you could do unregister class in FLTK
I would agree that (2) certainly does make sense, but not applicable because FLTK would be a part of the plugin, even statically linked to it. I think it would be however to FLTK benefit to have a clean build, meaning it could be re-loaded without memory leaks. As I mentioned before, wxWidgets allows running from the thread using ordinary function _beginthreadx(). I was just searching for toolkit suitable for this job, other choices would be wxWidgets (but it is huge) or Fox toolkit. It seems FLTK works fine, so I see how it develops. So far I only used a small sample. Best Regards, Mikhail > > On 25.06.2012, at 19:32, Mikhail Tchernychev wrote: > > > Thank you Matthias, > >=20 > > MFC DLLs take care about this issue by using AfxLoadLibrary() > > or something like that. Standard Win32 DLL does not clear after > > itself. > >=20 > > It seem to work fine. > >=20 > > What would you recommend is case if plugin needs its own > > GUI called on demand? If it only FLTK potentially dangerous to use > > this way or any other GUI toolkit as well? > > I see three issues. Mike may have more experience. > > 1: some window libraries do not like it when windows are created from = > any thread but the main thread. Make usere that the UI runs in the main = > thread and the worker bees run in the secondary threads > > 2: unloading a DLL does not always clear all allocations that need to be = > done on library loading. You may get memory leaks. It would be best to = > load the DLL only once during the life time of you application and then = > never unload it. You can still make the GUI go away, but IMHO you should = > not unload the library unless the app quits and never needs UI calls = > again > > 3: on OSX and MSWindows, applications may or may not launch differently, = > depending if they are command line or UI apps. This may not be an issue = > now, but could already interfere with security restrictions in the next = > version of the respective OS. > > Still, if it works for you and the folks who you build your app for, go = > for it. > > - Matthias= > _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
