Ian,
I want to thank you for your quick reply.
It appears that we're on the same page as to the options available:
(1) some kind of "reinit" within Fl_win32.cxx
This problem does not occur under MacOSX. I feel fairly confident, therefore,
that it is the implementation of Fl_Window and Fl (and the shadow
implementation of Fl_X) that is the key. However, I'm MAJORLY out of my depth
diving into that code. I didn't write it. While I understand about 10% of the
Windows UI model, enough to do Win32 development in a pinch, it looks like a
major opportunity to screw up.
I'd probably create a CleanUp() routine to hit on the way out, though. Simply
scavenge all of the statics and their initial values and put it all into one
routine.
(2) dynamic loading/unloading of fltkdll.dll
LoadLibrary() and FreeLibrary() aren't that hard to use, although what exactly
is in fltkdll.lib in light of no examples is slightly disconcerting. I've
found an example:
<http://research.cs.wisc.edu/graphics/Courses/559-f2003/fltkTutorial.htm>
But there is no _explicit_ loading within their example, so I wonder how badly
things will get borked.
I've pretty much decided to go for (2) with (1) as a backup plan. FLTK is too
useful to bail on yet. I found one other guy that tried this and ultimately
forked FLTK2 <http://gitorious.org/flptk> (Fast Light Plugin Toolkit), but
FLTK2 is dead... and I like the licensing terms for FLTK (static link, etc.)
This would preserve that.
When you wrote this:
"Maybe option (1) doesn't look so bad after all. Hmmm..."
..I nearly spit coffee all over my keyboard.
(3) There is actually a third choice that I don't like very much: Make an app
and pass my images and settings to it, call the app to put up the UI, and when
it is done pass the results back. Truly ugly and a last resort. We'll see if
I get that desperate.
Thanks!
-Chris
>
> 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).
> >=20
> > 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.
> >=20
> > I tried replacing Fl::run() with this construct:
> >=20
> > Fl::flush(); //allow dialog to appear prior to event loop
> > while(window->visible())
> > Fl::wait();
> > Fl::flush();
> >=20
> > It hasn't appeared to help. :(
>
>
> No, that's kinda what Fl::run() is doing anyway, so not likely to make =
> much difference...
>
>
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > 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().)
> >=20
> > 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();
> >=20
> >=20
> > Please help.
> >=20
> > (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!
>
> >=20
> >=20
> > UPDATE 8/29/12 3pm
> >=20
> > 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.
> >=20
> > 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.=20
> 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
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
