I have 177 plug-ins in one product line and 22 in another. Both would need to be split in this fashion. And of course, the Mac side "Just Works."
You can probably guess why I'm less than thrilled. I'm going to use a set of Memory-Mapped files to send the material back-and-forth. We'll see if CreateProcess() can be made to act modal. I already have examples of _most_ of the parts of this. Thanks, guys. -Chris > On 09/05/12 07:31, Chris Russ wrote: > > I've gotten approval from the bosses to attempt a two-part plug-in -- first > > part > > that grabs the image, second part that does the processing/UI. Now I have > > to do it. > > Doing it as a DLL is no biggie -- I've got a lot of experience with that, > > but making part be stand-alone in a different process, and yet not appear > > to be that way will be challenging. Especially that yield portion (I'd > > have to go > > async between the two parts so that the Photoshop stub continues to allow > > Photoshop to update). This gets ugly fast. > > I'd suggest try making a simple program that splits itself in two, > and then simulates the bidirectional async behavior you want. > > For instance, to simulate photoshop, make an image buffer, > and then try to share it between the two processes. > > Try to simulate the different kinds of interactions; if you > need to simulate that PS always needs to get some cpu, > create a loop that simulates that (prints messages to the > console every second), but has some kind of way to interrupt > photoshop to check for things to do from the FLTK gui process. > > I imagine PS might have a timer of some kind that you can > use to keep an eye on the pipe to see if new things to do > have come in from the FLTK process. > > I use this sort of technique (a simple standalone tool) > to test system calls I've never worked with before; > it helps to have a small bit of code so that porting > becomes easy to manage, then once the code works on > the target platforms, rewrite it or fit it into the > final app as a separate pass at the code. > > Basically, break everything into parts; perhaps start > with shared memory between two processes, then add > pipes/sockets/whatever, then a message queue between > the two processes, and tune it for keeping both sides > alive and non-blocking. > > Sometimes a message queue can be as simple as a semaphore > and an array of strings in shared memory. (if you find > working with pipes or sockets are too hard). > > > > Also, I have absolutely no objections to contributing to the cause. > > I'm pretty sure that someone else should be testing and checking > > in any changes that are worthwhile keeping, though. :) > > > > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
