> > I'm fairly sure I have not understood your explanation, so > what follows > > is likley to be wrong. However, on the basis of what I *think* you > > asked, I don't think this is going to work as you describe it. > > Sorry, I'll be more explicit.
I don't think my (lack of) understanding was from any failing on your part...! (More badly-formed ramblings from me follow.) > > > Also, since I am only ever calling FLTK from one thread, > I don't think > > > I need all the locking and unlocking. Is there a simpler way to Hmm, from your description it sounds (to me) as if there is more than one thread in your process, so you do need to use the lock/unlock methods - the fltk gui is one thread, and I imagine your haskell code is (at least) one other thread. Does your forkOS() call start another thread in the same process, or does it actually fork another process? I'm assuming it starts another thread in the same process - but if it is really forking a new process, then the story is very different... So, anyway, I (now) imagine that you have some complex piece of code in haskell, and are wanting to stick a GUI front-end onto it - or is that too much of a simplification? Given that's the position, a few points: - You might want to switch around the order of your threads; There's a basic problem that many hosts are not all that happy if you create/destroy graphics objects from any thread in a process other than the primary "main" thread (some OS/windowing systems have workarounds to allow that, but fltk uses a "lowest common denominator" approach and pretty much assumes all widgets are created/destroyed from the primary thread, as do many other toolkits.) So, you maybe want to look at making the fltk thread the primary entry-point thread, and have your haskell code run in the child thread(s). - Why does the haskell code have to get the gui events at all? What I do is have the fltk gui run in the main thread, then it can handle all gui interaction directly. Any gui interaction that has to be propagated to the child threads is handled in fltk callbacks which send messages on to the child threads. The child threads never see the gui events at all, just the messages that the GUI thinks they need. The child threads can (of course) use Fl::lock, unlock and awake to update GUI objects. (Assuming the objects have been created already in the main gui thread. The child still can't create/destroy widgets.) Or, since the gui and the children run in the same process space, they can easily communicate via shared memory or etc - although suitable precautions must be taken when reading/writing the data. Or... Does the haskell code already have a gui of it's own, which is eating the operator interactions, and you are trying to integrate this together with some added fltk widgets? That's a harder problem... In that case, I might look at having the fltk code run in a separate process (thereby ensuring it gets its own events) and use some form of IPC to handle the interaction between the two GUI's. SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
