Carlos & Ian.
I have many things to report.
Plan (1): hack FLTK to reinit properly.
- Fl_Win32.cxx is included within Fl.cxx and there are a lot of statics in
there. There are also a number of static classes that are created and hold
stuff, stuff that is Win32-specific. [This problem doesn't happen with MacOSX,
so I'm assuming the problem is Win32-only code]
I am unable to affect any change by resetting every static I can find.
Either I've missed the one(s) I need, or the problem is a lot more complex than
I would like.
Plan (2): Use FLTKDLL.DLL instead. I tried this, too. Fl_Input_Choice is an
unhappy camper in this environment (resize is the culprit). But once I got it
to link, the same problem appears as expected. So, I put in an
Load/FreeLibrary hack and noticed two problems. The first is that even with an
explicit unload on the first time through and then an explicit load, followed
by an unload on the way out, it simply crashes. There's something subtle about
how Microsoft handles DLLs coming in and out, and I crash the moment I
completely unload the FLTKDLL and return to Photoshop. The bigger problem is
that my plugin has FLTKDLL in it's manifest list to load, so if I've got N
plug-ins, the reference count is that high and it may not be possible to
unload/reload the DLL enough times to get it right. I have to understand
libraries and error handling better in order to pull this off.
Plan (3): Split my plugin into two parts: (a) - a pure Photoshop plug-in and
(b) the UI part that uses FLTK (static). This will probably work, but it is a
pain in the *ss. I may not have any other choice, though.
re: Carlos' notes. The Photoshop DLL API is fundamentally pure C. I don't
really see how your method would work. The name conflict part doesn't seem to
be the gravamen of my problem -- but rather the event handling. My
demonstration in case (1) (static) is that fltkwindow->show() doesn't actually
show the window. I skipped the Fl:run() step and just popped up a window to
see where the problem lies, and it seems that the window isn't getting
constructed. That made me look into Fl.cxx and in turn Fl_win32.cxx for the
problem.
What I've found is an interesting set of code that I completely do not
understand involving Fl_GDI_Graphics_Driver (win32 only, btw), OLE/COM, how
handlers are registered, and how the list of currently open Widgets is kept
track of. Fl_Win32_At_Exit() is a crazy maneuver. My suspicion is that there
is a memory leak or something not getting done with a ->hide() operation or the
window deconstructor.
At this point I'm pretty much going to have to go plan (3) because of the
amount of time already spent on (1) and (2). I will drive through the
implementation of Fl::handle and Fl:event_dispatch to see why your example
works, but I think VST has a much different calling model than PS.
Thank both of you for your help and I will continue to post info and I come up
with stuff.
-Chris
> Hi Chris. Sorry for the delay. Ok, so here´s how I solved the situation with
> FLTK and audio plugins - hope this works for you too:
>
> First, I´m not using FL::run() or FL::wait(). What I do is have something
> like this:
>
> static int FLTK4VST::FLTK4VST_eventDispatcher_(int e, Fl_Window *w)
> {
> int ret = Fl::handle_(e, w);
>
> if (ret)
> Fl::flush();
>
> return ret;
> }
>
> Then in the constructon of my plugin I have this:
>
> FLTK4VST::FLTK4VST (VstInt16 width, VstInt16 height, void *fx) : AEffEditor (
> (AudioEffect*)fx )
>
> {
> //...
> fltkWindow_ = 0;
> Fl::event_dispatch(FLTK4VST::FLTK4VST_eventDispatcher_);
> //...
>
> }
>
> So the system will call my event dispatcher method, which in turn will send
> the events to the standard FLTK event handler, but by checking FLTK´s
> handler return value, I can force a redraw when it is actually needed).
>
> Second, I have to control carefully the name of the window class that is
> being registered by my plugin´s instance... I have this static function:
>
> static void FLTK4VST::getXClassName_(char *name)
> {
> static int r1 = rand();
> static int r2 = rand();
> static int r3 = rand();
>
> sprintf(name, "FLTK4VST_%d_%d_%d", r1, r2, r3);
> }
>
> Which ensures that every object of a given DLL will have a unique class name
> (and different than the default "FLTK"), and whenever a different DLL is
> loaded, any object of that other DLL will have a unique class name too (and
> again, not "FLTK"). Since PS isn´t really unloading the DLL when closing the
> plugin, this is stil important, even if you can´t have 2 plugins operating
> at the same time. Of course my function isn´t perfect - relying on rand()
> isn´t the most elegant solution but works as proof of concept.
>
> Now, whenever I´m are ready to build and show my window, I´m doing this:
>
> /////////////////////////////////////
> if (fltkWindow_ == 0)
> {
> Fl::visual(FL_DOUBLE|FL_INDEX);
>
> char name[256];
> getXClassName_(name);
>
> fltkWindow_ = new Fl_VST_Window(windowRect_.left + windowRect_.right,
> windowRect_.top + windowRect_.bottom);
> fltkWindow_->xclass(name);
> fltkWindow_->set_override();
>
> buildEditor_(); // Create the different widgets that make up your GUI
> }
>
> fltkWindow_->show();
> //////////////////////////////////////
>
> Finally, when you want to destroy your main plugin´s window:
>
> ////////////////////////////////////
> #ifdef WIN32
> char t[256];
> getXClassName_(t);
> BOOL res = UnregisterClass(t, 0);
> #endif
>
> Fl_VST_Window *tmpFltkWindow = fltkWindow_;
> fltkWindow_ = 0;
> delete tmpFltkWindow;
> /////////////////////////////////////
>
> For more information on why or how this is working you can chek the
> Fl_X::make(Fl_Window* w) in the Fl_win32.cxx file and the Windows API.
>
> Hope this works for you. And I really hope that all the code I´ve posted
> here comes out formated the right way - I´ve had very bad luck with the
> formatting of my posts in the past.
>
> > I'm deeply curious how you solved the problem. And what timezone are you
> > in that you responded at 6:15am EDT?
>
> I´m at GMT -5, but as you can get from the time of both my previous post and
> this one, I´m not getting much sleep lately. :D
>
> Best regards,
>
> Carlos
>
>
>
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
