Greg, So the fltkWindow->show() function is failing because the other toolkit (whatever Adobe uses) is eating the events to make the window come up? But straight Win32 calls are okay? They might have some kind of funky event chain in place.
Hmmmm. Separate process is a royal pain in the @$@#$%. Not only passing images over the "wall" is a pain, but remaining modal in that case would be a challenge. I'd hate to have to abandon FLTK, but that's basically what I'm looking at. At least on the PC. cr*p. You guys did some nice work. -Chris > On 09/04/12 12:11, Chris Russ wrote: > > But your approach is worth trying. I can spawn a new thread > > for the UI after copying the image out of Photoshop. > > Let me give that a shot. > > Hi Chris, > > Just clarifying: I'm not recommending a separate /thread/, > but rather a separate /process/. > > Threads will share the same event queues and event libraries from the > OS, > and therefore a potential for contention over events and message queues > can occur > causing unpredictable behavior in one toolkit or the other, something > I'd think > you'd want to avoid. > > I *think* any success you've had so far has more to do with luck > that the two toolkits don't immediately show confusion over events. > > Both FLTK and PS's event loops will be contending over the same > events at times, so you really would want to avoid that, I'd think. > > With separate processes, event queues will be entirely separate, > so there's no chance PS's event queue management conflicting with > FLTK's, > and no chance that internal changes to PS from one release to the next > would affect FLTK's event handling either.. only the DLL might have to > change. > > For what I'm recommending, when your DLL initializes, it would > immediately > start a child 'helper' process that has all the FLTK code in it, and > from > there, all subsequent interaction between the DLL and FLTK be done via > bi-directional IPC (Inter-Process Control), using either > pipes/sockets/mmap, > the DLL acting as a "liaison" between PS and FLTK. > > So event triggers from PS would send IPC messages to the FLTK process, > and vice-versa, clicks in the FLTK GUIs would send messages to the DLL > for PS to handle, the DLL acting as the arbitrator. > > So in other words: > > Photoshop Process | FLTK 'helper' process for the DLL > ----------------------|----------------------------------- > | > PS | > \ | > your plugin <---|---> fltk-helper-process > | (child process of your plugin+PS) > | > > > The problem appears to be one of re-entrancy. > > You might be right about the re-entrant issues, but I think > a separate problem is purely a design issue; one should probably > avoid two different graphics toolkits running in the same process. > > But I defer to others on the FLTK dev team, because I'm not as familiar > with the lower level FLTK event code as others on the team.. > I'm more of a widget and systems programmer. > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
