On 29 Aug 2012, at 20:06, Chris Russ wrote: > I've wedded FLTK 1.3 to the Photoshop plug-in (CS5 SDK) and have been > extremely happy with write-once, use-many. Coding on the Mac has been > straightforward and I've just ported my UI to the PC. (Win7). > > Here's the problem -- the plug-in (DLL) will run once. (64-bit or 32-bit > doesn't matter) The second time I invoke it, the UI fails to come up and I'm > stuck in some kind of infinite loop waiting for events that I cannot get > because there is no window. > > I tried replacing Fl::run() with this construct: > > Fl::flush(); //allow dialog to appear prior to event loop > while(window->visible()) > Fl::wait(); > Fl::flush(); > > It hasn't appeared to help. :(
No, that's kinda what Fl::run() is doing anyway, so not likely to make much difference... > > It appears that the w->show() function on my window (and it can be as > primitive as an empty Fl_Window) simply fails. Fl_Double_Window fails, too. > > As you can see above, I've added an Fl::flush() call after the w->show(), and > it still fails most of the time. Yet the w->shown() flag is TRUE at that > point. I can't tell if this is because of a w->hide() that puts the window > down from the previous execution or what. > > Other tidbits -- Adobe loads the DLL and then leaves it open, so it isn't > clear that my environment is getting reinitialized. I've taken care to > reinitialize all of MY static initialization variables, but that hasn't made > a difference. Yes, it is probable that key parts of fltk are not being re-initialized, as you say; for (perhaps now largely historical) reasons, fltk has some global data that will be in the "wrong" state the second time through. > Adobe's MessageBox function still works -- I can put up one of their windows > even when the w->show() function fails (and that is how I figured out that it > hadn't crashed at this point and that it didn't make it past the while-loop > or Fl:run().) > > Is there some kind of cleanup call I should make on the way out from the > first time through? Not as such, not easily anyway, though I imagine it might be feasible to identify the key globals and have a function that explicitly resets them. > I'm inside of a DLL at this point and have been called by someone else's app > (Photoshop), so we can't leave with exit(); > > > Please help. > > (originally posted under fltk.bugs -- don't know if that is a better place > than here to post) This is a better place to post; note that fltk.bugs is really meant for the auto-generated output from the STR system - indeed I'm not all that sure why it is writeable at all! > > > UPDATE 8/29/12 3pm > > Adobe's documentation suggests that after CS4 they do not unload DLLs/plugins > between calls for speed. This means that, as I surmised, any FLTK > initialization only takes place once. I'm about to dive into using > fltkdll.dll instead so that I can _explicitly_ reinitialize fltk between > sessions. Since this code always works like a champ the first time, I think > I can make each time be THE. FIRST. TIME. > > But if anyone has a suggestion, I'm all ears. OK, here we go: Though note that you are somewhat outside of fltk's "comfort zone" with this, so fun times may lie ahead... Option (1) as suggested above is figure out which bits of the fltk global state data are key and write a wrapper function to re-init them explicitly on "the next" pass through. Presumably you could set your own static global to indicate if this was needed or not. Don't fancy that much, to be honest, but might well be easy to do and might even work! Option (2) is to not let PS or the Windows runtime load the fltk DLL for you, but instead to load it yourself - then (assuming you know when you are being told to exit) you can explicitly unload it again on the way back out. There are examples of doing this sort of thing in the fltk library itself, e.g. in Fl_Preferences.cxx around line 97 where we LoadLibrary RPCRT4.DLL dynamically *if we need it* rather than binding to it at runtime. Indeed, grep'ing the source tree we call LoadLibrary in a few places I notice... Anyway, the idea would be to try to create a wrapper that would load fltk explicitly that way, then call FreeLibrary again on the way back out. With a bit of luck, downhill and with a following wind, that might be enough to stop PS loading the DLL for you, and it might all Just Work. Or, you know, maybe not... I've never actually tried this. Maybe option (1) doesn't look so bad after all. Hmmm... _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
